fix(ci): quote store:: test filter so db-checks.yml parses on GitHub

[hyperpolymath]

db-checks.yml has never run. The step

run: cargo test --lib store::

ends in ::, which is not a valid unquoted plain scalar in YAML block context, so GitHub rejects the entire workflow file at parse time: startup_failure, zero jobs, and — the part that hides it — no check run at all. gh pr checks shows nothing missing, because a workflow that never parsed never reports.

Quoting the value fixes it. Verified with a strict YAML parse before and after; this was the only file of the 29 in the repo that failed to parse (all 33 in echidna are clean).

Once merged, gh run list --workflow=db-checks.yml should show a real run for the first time — which also means the migration/schema-drift gate it contains starts actually gating.

[gitar-bot]

CI failed: CI failures occurred due to A2ML manifest validation errors and a missing local workspace dependency (`gitbot-shared-context`) required by Cargo.

Overview

Two distinct failure patterns were found across 3 analyzed CI logs: an A2ML manifest validation failure and a missing local cargo dependency during the Rust build/check step.

Failures

A2ML Manifest Validation Failure (confidence: high)

• Type: test
• Affected jobs: 90323636308
• Related to change: yes
• Root cause: The A2ML validation script (.githooks/validate-a2ml.sh) found 2 errors across the scanned .a2ml files: missing required identity fields (agent-id, name, or project) and a missing SPDX-License-Identifier in the first 10 lines.
• Suggested fix: Fix the validation errors in the .a2ml files by adding an SPDX-License-Identifier comment within the first 10 lines and ensuring required identity fields are present.

Missing Local Cargo Dependency (confidence: high)

• Type: dependency
• Affected jobs: 90324514566, 90325425888
• Related to change: unclear
• Root cause: The project depends on a local workspace or path dependency gitbot-shared-context located at /home/runner/work/shared-context, but that repository or directory was not checked out or placed in the expected path on the CI runner.
• Suggested fix: Add a step in the GitHub Actions workflow to check out the shared-context repository into the sibling directory /home/runner/work/shared-context or adjust the dependency configuration in Cargo.toml.

Summary

• Change-related failures: 1 (A2ML manifest validation errors)
• Infrastructure/flaky failures: 0
• Recommended action: Update the manifest files to satisfy A2ML validation rules and ensure the required local dependency repository is checked out in CI.

Code Review ✅ Approved

Quotes the store:: test filter in db-checks.yml to resolve a YAML block context parsing error that prevented the workflow from running on GitHub. No issues found.

Auto-approved and auto-merge armed: No blocking issues found.
Please see Auto-approve Docs for details on setting custom approval criteria. — merges when pipeline and required approvals pass.

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[gitar-bot]

⚠️ Gitar auto-approved this PR but could not enable auto-merge: auto-merge is disabled for this repository — enable "Allow auto-merge" in the repository settings.

[gitar-bot]

Gitar has auto-approved this PR and enabled auto-merge (configure)

[hyperpolymath]

The quoting fix was necessary but not sufficient — pushed a second commit

After the first commit, the run from 0407c7e still completed with zero jobs, and GitHub still displayed the workflow by path (.github/workflows/db-checks.yml) rather than by its name (DB Checks) — the tell that it never became a real workflow run:

gh api .../actions/runs/30332637328/jobs  →  {"n": 0, "names": [], "conclusions": []}

So there was a second, independent defect:

jobs:
  migrations:
    if: hashFiles('Cargo.toml') != ''    # ← fails the run before any job exists

hashFiles() resolves against the runner workspace, which does not exist when a job-level if is evaluated. The expression errors while the run graph is being built, so the run ends as failure with no jobs and no usable logs — a failure mode that looks nothing like a YAML error but has the same practical effect: the gate never ran.

Both guards were also pointless: Cargo.toml (4 KB) and Cargo.lock (128 KB) are committed and always present.

Same pattern, same symptom, one more file

Correlating job-level hashFiles() usage against workflows that appear by path in run history:

workflow	job-level hashFiles()	shows by path (never a real run)
db-checks.yml	yes	yes
cargo-audit.yml	yes	yes
boj-build.yml	no	yes — different cause, still open
e2e.yml	no	yes — different cause, still open

cargo-audit.yml is fixed in the same commit. boj-build.yml and e2e.yml are also not running but fail for some other reason; they are outside this PR's scope and worth a follow-up issue.

Net effect once this lands: the migration/schema-drift gate and the dependency audit both start actually gating, for the first time.

[hyperpolymath]

Result: the gate is real now — and it immediately told us something true

With both fixes in, db-checks produced an actual job with actual steps for the first time in its history:

Migrations + schema drift          → failure
  ✓ Set up job          ✓ Checkout        ✓ Install Rust toolchain
  ✓ Cache cargo         ✓ Install sqlite3 CLI
  ✗ Build echidnabot
  – (remaining steps skipped)

Compare with the previous run: {"n": 0, "names": [], "conclusions": []} — no jobs at all.

It fails at the build for the reason this repo already documents:

error: failed to get `gitbot-shared-context` as a dependency of package `echidnabot v0.1.0`
  failed to read `/home/runner/work/shared-context/Cargo.toml`
  No such file or directory (os error 2)

Cargo.toml:29 carries gitbot-shared-context = { path = "../../shared-context" }, which only resolves inside the gitbot-fleet monorepo layout — the acknowledged debt in .claude/CLAUDE.md ("do not 'fix' it unless explicitly asked", issue #18). It is also why Rust CI fails on main today.

I have not touched it, per that instruction.

So this PR does what it claims: it converts a workflow that could never run into one that runs honestly. It cannot go green until the path dependency is resolved (vendor it, publish it, or make CI check out the monorepo) — but that is now visible as a real red gate instead of an invisible absence, which is the point.

Worth noting for whoever picks up #18: fixing that one dependency should turn db-checks, cargo-audit, and Rust CI green together.