ci: open a PR automatically when a newer Go patch ships - #30
Open
kshahbw wants to merge 3 commits into
Open
Conversation
CI runs only on push-to-main and pull_request, so a Go standard-library CVE stays invisible until somebody opens a PR. Five stdlib CVEs landed against 1.26.5 on 2026-08-11 and went unnoticed for three days, then surfaced on an unrelated feature PR whose author had to stop and diagnose a failure they had not caused. Weekly cron compares the go directive in go.mod against go.dev's release list and opens a bump PR when the pinned series has a newer patch. Patch releases only. A minor bump can change language and toolchain behavior, so it stays a human decision; the query is filtered to the series already pinned in go.mod. Uses include=all when querying go.dev. Without it the endpoint returns only the two newest minor series, so the pinned series would drop off the list the moment a new Go minor shipped and bumps would stop silently. Verified that 1.25 and 1.24 still resolve with the flag set. Skips when a branch for the target version already exists, so a re-run while a bump PR is open is a no-op. Verified against the currently open chore/bump-go-1.26.6. Scripted with git and gh rather than a third-party action, following the Homebrew formula bump in release.yml. Known limitation, documented in the generated PR body: GitHub suppresses workflow runs on pull requests opened with GITHUB_TOKEN, so the bump PR arrives without CI. Minting a token from the existing GitHub App and adding cli to its repositories list would remove that step.
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
ckoegel
approved these changes
Aug 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
BLUF
Weekly cron that opens a Go patch-bump PR when one is available. Closes the gap that let five stdlib CVEs sit unnoticed for three days and then land on an unrelated feature PR.
The gap
ci.ymltriggers only onpush: [main]andpull_request. So when a Go standard-library CVE is published, nothing runs — the repo stays green because nothing asked it a question.That's what happened this week: main last ran CI on 2026-08-11 and passed. Five stdlib CVEs landed against 1.26.5. Nobody knew until #27 (an unrelated 10DLC feature PR) ran on the 14th, and its author had to stop and diagnose a failure they hadn't caused. Fixed in #28.
What this does
Every Monday, compare the
godirective ingo.modagainst go.dev's release list. If the pinned series has a newer patch, open a PR.Patch releases only, deliberately. A minor bump (1.26 → 1.27) can change language and toolchain behavior and deserves a human decision, so the query is filtered to the series already in
go.mod.Scripted with
gitandghrather than a third-party action, following the Homebrew formula bump inrelease.yml(#16 replaced an action with a script for the same reason).Verified before opening this PR
Not just written — actually exercised against the live API:
Duplicate guard, tested against the currently-open #28:
The
include=allsubtlety. Without that flag go.dev returns only the two newest minor series, so the pinned series would drop off the list the moment a new Go minor shipped and bumps would stop silently — the worst failure mode for a safety net. Confirmed older series still resolve with it set:Also guards against going backwards (
sort -V) in case go.dev ever reorders its list, and fails loudly rather than opening an empty PR if theseddoesn't match.Known limitation — read before merging
The generated PR will not have CI runs on it. GitHub deliberately suppresses workflow runs on pull requests opened with
GITHUB_TOKEN, so workflows can't trigger themselves. The generated body says so and tells the reader to close/reopen or push an empty commit.That matters here specifically: the reason to take a bump is usually a
govulncheckfinding, and only CI confirms it.The clean fix is to mint a token from the existing GitHub App — the one
dispatch-docsitealready uses inrelease.yml— and addclito itsrepositories:list. App-token PRs do trigger workflows. I didn't do that here because the app is currently scoped toapi-specsonly and widening it is your call, not mine.Not included
Two adjacent gaps I found but left alone, happy to do either:
govulncheck. This workflow only reacts to a Go release. A CVE with no patch yet still goes unnoticed. Addingschedule:toci.ymlwould cover that — about four lines.ci.yml:58installsgovulncheck@latest, so the scanner changes under you between runs and the security job can start failing with no repo change. Pinning it would make CI reproducible.