Two defense-in-depth follow-ups to the write-lock burst fix:
- 05.1 README Sync: add data/inventory.sql to paths-ignore, alongside the
already-ignored data/inventory.yaml. It is a generated artifact, never
hand-edited, so a push touching it should not wake the README sync.
- 07.1 PR Guardian: add [skip ci] to its auto-correction commit. Guardian
pushes the fix back to the PR head branch, whose synchronize event otherwise
re-runs Guardian (Gemini calls) and the markdown linter on Guardian's own
cosmetic commit - exactly the CI minutes the workflow's concurrency comment
says it wants to save. Base branches are unprotected, so no required check is
stranded; human commits (no [skip ci]) still trigger Guardian normally.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two defense-in-depth follow-ups to the write-lock burst fix:
- 05.1 README Sync: add data/inventory.sql to paths-ignore, alongside the
already-ignored data/inventory.yaml. It is a generated artifact, never
hand-edited, so a push touching it should not wake the README sync.
- 07.1 PR Guardian: add [skip ci] to its auto-correction commit. Guardian
pushes the fix back to the PR head branch, whose synchronize event otherwise
re-runs Guardian (Gemini calls) and the markdown linter on Guardian's own
cosmetic commit - exactly the CI minutes the workflow's concurrency comment
says it wants to save. Base branches are unprotected, so no required check is
stranded; human commits (no [skip ci]) still trigger Guardian normally.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The V2 pipeline is meant to advance only via its workflow_run chain
(03.1 -> 03.2 -> 03.3 -> 04.1), which [skip ci] does not affect. But 03.2 and
03.3 committed data/inventory.yaml WITHOUT [skip ci], so their bot pushes also
matched push: path triggers: 03.2 re-triggered itself (and 03.3 triggered it
backward) on data/inventory.yaml, and data/inventory.sql woke 05.1. That
redundant fan-out flooded the shared develop-git-write-lock group; with
cancel-in-progress: false GitHub keeps only one pending run per group, so
superseded runs were auto-cancelled (0 jobs, no logs) - e.g. run 29263339507.
Every other develop-pushing stage (03.1, 04.1, 05.1, 09) already carries
[skip ci]; this completes the pattern on the two stages that were missing it.
The workflow_run chain, schedule, and workflow_dispatch entry points are
unaffected.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The V2 pipeline is meant to advance only via its workflow_run chain
(03.1 -> 03.2 -> 03.3 -> 04.1), which [skip ci] does not affect. But 03.2 and
03.3 committed data/inventory.yaml WITHOUT [skip ci], so their bot pushes also
matched push: path triggers: 03.2 re-triggered itself (and 03.3 triggered it
backward) on data/inventory.yaml, and data/inventory.sql woke 05.1. That
redundant fan-out flooded the shared develop-git-write-lock group; with
cancel-in-progress: false GitHub keeps only one pending run per group, so
superseded runs were auto-cancelled (0 jobs, no logs) - e.g. run 29263339507.
Every other develop-pushing stage (03.1, 04.1, 05.1, 09) already carries
[skip ci]; this completes the pattern on the two stages that were missing it.
The workflow_run chain, schedule, and workflow_dispatch entry points are
unaffected.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Nubenetes Bot
InakiandGitHub
dependabot[bot]andGitHub
github-actions[bot]andGitHub
Inaki FernandezandClaude Opus 4.8