-
Notifications
You must be signed in to change notification settings - Fork 225
Description
🏥 CI Failure Investigation - Run #35546
Summary
TestHashConsistencyAcrossLockFiles in pkg/parser fails because the frontmatter hash stored in the # frontmatter-hash: header of many generated .lock.yml files is out of sync with the freshly edited workflow .md sources. Running the hash‑consistency script locally shows 142 workflows where the computed hash differs from the hash currently embedded in the lock file.
Failure Details
- Run: 22007809849
- Commit:
d77129cc3592fd69b17292d278745c8eee1e3fb5 - Trigger: push to
main
Root Cause Analysis
The commit touches hundreds of .github/workflows/*.md files and the shared fragments they import, but the corresponding # frontmatter-hash: comments in the generated .lock.yml files were not regenerated after those edits. Because the parser’s hash includes the resolved imports, any change to an imported shared snippet invalidates the hash in every dependent lock file. The TestHashConsistencyAcrossLockFiles test therefore detects 142 mismatches between the hash it computes from the markdown and the stale hash stored in the lock files.
Failed Jobs and Errors
- job:
testTestHashConsistencyAcrossLockFiles(packagegithub.com/github/gh-aw/pkg/parser) fails after verifying 150 workflows. The failure report only shows the final output because the test continues scanning; the job log ends withFAIL github.com/github/gh-aw/pkg/parserandTestHashConsistencyAcrossLockFilesreported as failed.
Investigation Findings
- A custom Python reimplementation of
ComputeFrontmatterHashFromFileconfirmed that 142 workflows now produce a different hash than the value currently encoded in their.lock.ymlfiles. Example discrepancies:agent-performance-analyzer.md: computed hash8d0cc98d2e4f...d4570, lock file still hasecdacefe...7302a.daily-code-metrics.md: computed17e8d929ae6751...309d, lock stores90cdc96a45c8d6...6358d48.workflow-generator.md: computed5a485cf2...f453, lock stores1bf8a53a...65408c.
- Because the hash is recomputed on every test run, once the frontmatter (or any imported shared workflow) changes,
gh aw compile/make recompilemust be rerun to refresh every lock file. That step was either missed or incomplete for this batch of changes.
Recommended Actions
- Re-run
gh aw compile(ormake recompile) to regenerate every.github/workflows/*.lock.ymlso the# frontmatter-hash:line matches the latest markdown frontmatter. - Verify the fix by re-running the unit test locally (once the Go 1.25 toolchain is available):
go test -run TestHashConsistencyAcrossLockFiles ./pkg/parser. - Commit the regenerated lock files and rerun
make agent-finish/CI to ensure no other hash mismatches remain.
Prevention Strategies
- Include
make recompile(or an equivalentgh aw compileinvocation) as part of the workflow-editing checklist every time shared snippets or workflow front matter change. - Consider adding an automated pre-merge check that reruns
TestHashConsistencyAcrossLockFilesor compares# frontmatter-hash:comments against a quick hash script before pushing.
AI Team Self-Improvement
Before touching workflow frontmatter (including shared fragments), run make recompile and rerun TestHashConsistencyAcrossLockFiles. Keep the compiled lock files on-disk so the frontmatter-hash commentary is always updated alongside the markdown.
Historical Context
This test has caught stale lock files in previous runs (see CI Failure Doctor run #35529). Whenever the shared imports move or shared snippets are edited, the downstream lock files must be regenerated or TestHashConsistencyAcrossLockFiles will fail again.
AI generated by CI Failure Doctor
To add this workflow in your repository, run
gh aw add githubnext/agentics/workflows/ci-doctor.md@ea350161ad5dcc9624cf510f134c6a9e39a6f94d. See usage guide.
- expires on Feb 15, 2026, 1:01 AM UTC