ci: stop security patches from stranding on main - #117
Conversation
Dependabot security updates ignore target-branch and land on main, where nothing tested them and nothing carried them back to dev. A browserslist advisory sat there while the release train kept building the vulnerable lockfile, and the audit gate only fired inside the Docker build, after publish had already pushed v1.3.5's commits to main. - test PRs to main, not just dev, so security patches are gated - fail the release audit in check, before publish mutates main - open an issue when dev falls behind main - drop the security-updates group that never applied
Counting commits fired after every release: the version bump lands on main only, by design, so dev is behind every single week and the issue would have been weekly noise for a healthy state. Filter the release train's own commits out by author instead, so it reports only patches that reached main and never made it back to dev. Checked against both v1.3.4 and v1.3.5: silent after each release, and it fires on exactly the browserslist merge that stranded. Closes the issue once dev catches up, so a stale one cannot mask the next.
|
Reviewed this against the actual history and found the sync workflow was wrong, now fixed in 4a37924. As first written it reported how far dev was behind main. That fires after every release: the version bump and changelog land on main only — dev deliberately never carries VERSION — so main was 4 commits ahead after v1.3.4 and 9 after v1.3.5. It would have filed a "dev is behind" issue every week for a state that is supposed to be true. It now reports what is stranded instead, filtering out the release train's own commits by author (
It also closes its own issue once dev catches up, so a stale one cannot mask the next strand. One thing worth being straight about on the rest of the PR: running the integration suite on PRs to main would not have prevented this failure. #116 was never merged, not never tested. That change is defence-in-depth and a prerequisite for auto-merging on main later. The audit-gate change is the one that pays for itself today. |
1 participant
Follow-up to the v1.3.5 release failure (#115). That run failed because
browserslist≤4.28.6 tripped the Dockerfile'snpm audit --audit-level=highgate on both build architectures. The fix (#116) already existed — it had been open against main for a day.Why it went unnoticed
dependabot.ymlsetstarget-branch: dev, which applies to version updates only. Security updates ignore it and are raised against the default branch, main. Three things followed from that:docker-integration-tests.ymlran onpull_request: branches: [dev], so Bump browserslist from 4.28.4 to 4.28.9 in the npm_and_yarn group across 1 directory #116 got CodeQL and nothing else — not the 41-test suite that would have flagged the lockfile.dependabot-auto-merge.ymlalso only triggers on dev, so a main-targeted security PR waits on a human indefinitely.The
npm-securitygroup independabot.ymlimplied advisories arrive on dev, grouped and prefixed. They never did — #116 came through asnpm_and_yarn, ungrouped, with nodeps:prefix.Changes
docker-integration-tests.yml— run on PRs to main as well as dev, so security patches face the same gate everything else does.weekly-security-release.yml— thecheckaudit fails instead of warning. It already warned on 2026-09-07; the Dockerfile then hard-failed on the same advisory three jobs later, but by thenpublishhad merged dev and pushed the version bump. Failing incheckleaves main untouched, so the re-run after the patch lands is clean.sync-main-to-dev.yml(new) — opens an issue when main is ahead of dev.dependabot.yml— drop the deadnpm-securitygroup, document where security PRs actually go.Two things deliberately not done
Auto-merge for main-targeted security PRs.
maincurrently has no branch protection, sogh pr merge --autowould merge on creation without waiting for the suite — the opposite of the intent. Worth enabling once main requiresTest Summary; happy to do that separately.A sync PR instead of an issue. A PR opened with
GITHUB_TOKENdoes not triggerpull_requestworkflows, soTest Summarywould never run and the PR would block on dev's required check forever. There is no PAT in the repo. An issue can't get stuck.Timing
Targeting dev per convention, so these reach main at the v1.3.6 release. The audit gate and sync workflow run from main's copy, so they take effect from the release after that.