ci: split the toolchain currency report out of the vulnerability scan - #28
Merged
Conversation
The weekly toolchain-currency report is the only thing watching the mise pins, and it can only signal by failing. Clearing a known-benign lag keeps the next genuine one visible rather than lost in a run that is already red.
The scan reports an advisory; the currency report reports that a pin moved upstream, and it can only surface at all by failing. Sharing one workflow left a red result meaning either thing, and a failure notification carries the workflow name rather than the job name — so the ambiguity landed hardest on the scheduled run, the one case where neither has a push-driven backstop. Two claims did not survive scrutiny while moving them, and both were published in SECURITY.md rather than confined to a comment: GitHub notifies on every completed run by default, with failed-only an opt-in account setting, and the 60-day scheduled-workflow disable runs on one repository-level clock rather than one per workflow. The new workflow keeps a pull_request trigger with the job guarded off it, so the file is still parsed on any PR that edits it — a schedule-only workflow has no event that would catch a malformed edit, and its recurring editor is a bot merging on green checks. Its mise pin moves here too, since Dependabot bumps the action SHA but never the version input.
Taken over from the open Dependabot PR, which targets this action on a line in vuln.yml that the preceding commit deletes — so landing it there would conflict rather than apply. Bumping it on the action's new home instead lets the bot's PR close on its own once it sees the pin at the target version.
The report exists so a red run says which concern fired, and it had two ways to
say the wrong thing. A failed or silent mise yielded an empty command
substitution, which compared against {} raised the pin-lag error — a broken
reporter reported as stale pins. Capturing once and branching on emptiness
separates them, and testing inside `if` keeps the errexit shell from exiting
there with no annotation at all.
The pull_request trigger went the other way: it claimed to catch a bad action
pin, which the job it guarded cannot reach, because a skipped job resolves no
uses:. Drop it rather than keep a mechanism that does not do what it says; what
remained was parse reachability resting on a premise GitHub does not document.
State the notification behavior only at the strength GitHub documents — runs you
triggered, failed-only an option, and a scheduled run notifying its creator —
and keep the 60-day condition in SECURITY.md alone, with both workflows pointing
at it instead of carrying their own copies.
Two adjacent supply-chain bullets stated who a re-enabled scheduled workflow notifies. The first now covers scheduled-run routing in full, so the second points at it rather than restating a fact that would then have to stay true in two places.
There was a problem hiding this comment.
Pull request overview
This PR separates the weekly toolchain currency report from the govulncheck vulnerability scan so red workflow results clearly indicate whether an advisory landed vs. a pin is behind upstream, and updates documentation to reflect the split and GitHub notification semantics.
Changes:
- Split the toolchain pin-lag report into a dedicated
Toolchain currencyworkflow and remove it fromVulnerability scan. - Update supply-chain/security documentation to describe the two workflows and clarify scheduled-run/notification behavior.
- Bump
justfrom 1.57.0 to 1.58.0 (with correspondingmise.lockupdate) and update the pinnedjdx/mise-action+miseversion used for the report.
Reviewed changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
SECURITY.md |
Clarifies CI/scanning posture and documents the new split between vulnerability scanning and toolchain currency reporting. |
CONTRIBUTING.md |
Updates contributor docs to reference the separated workflows and their intent. |
mise.toml |
Bumps the local just pin. |
mise.lock |
Updates resolved just artifacts/checksums to match the new pin. |
.github/workflows/vuln.yml |
Removes the toolchain report job; retains only the vulnerability scan with updated schedule commentary referencing SECURITY.md. |
.github/workflows/toolchain.yml |
Adds the dedicated scheduled/dispatch toolchain currency workflow (with distinct failure messaging). |
.claude/rules/toolchain-ci-parity.md |
Updates parity-rule references/paths to include the new workflow and reflect the moved mise-action usage. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+62
to
+63
| run: | | ||
| mise outdated --bump --local | tee -a "$GITHUB_STEP_SUMMARY" |
Owner
Author
There was a problem hiding this comment.
Fixed in b4789f6 — the summary pipeline no longer decides the step, so a failing mise now reaches the guarded call below and fails with the annotation rather than bare.
Under errexit the summary pipeline exited the step before either annotation could run, so a failing mise produced the one red result this workflow cannot explain — precisely the gap it exists to close. The summary is cosmetic, so its status no longer decides the step; the authoritative JSON call below is guarded and still names the cause.
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
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.
Overview
The weekly vulnerability scan ran two jobs of different natures under one name:
govulncheck, where red is rare and means an advisory landed, and a toolchain currency report, where red is routine and means a version moved upstream. Both a failure notification and the Actions run list identify a run by its workflow, so one workflow carrying both left a red result meaning either thing — worst on the scheduled run, the only one with no push-driven backstop. Each concern now has its own name.SECURITY.mdalso carried a claim that GitHub "notifies on failed scheduled runs and stays silent on successful ones," which is not what GitHub documents: the default notifies you about every completed run you triggered, and failed-only is an option you select. That claim and the 60-day scheduled-workflow disable beside it are now stated at the strength the documentation supports, once each, with both workflows pointing at them rather than carrying copies.This also clears the pin lag that made the scan go red in the first place:
just1.57.0 to 1.58.0 with its lockfile, and thejdx/mise-actionpin — both itsversion:input, twelve mise releases stale and reported by nothing, and its SHA, taken over from the open Dependabot PR whose target line this change deletes.How it works
The currency report has to fail to be heard at all, since
mise outdatedexits 0 whether or not a pin has moved. That left a broken reporter indistinguishable from a stale pin: a failed or silentmiseyields an empty command substitution, which compared against{}raised the pin-lag error. It now captures once and branches on emptiness so the two carry distinct messages, with the test insideifso the errexit shell doesn't exit first with no annotation.Neither workflow becomes a required check — the ruleset still requires
test,lint, andrelease-configonly.Issue references
Related to #16 — this adds a workflow file, and with no
pull_requesttrigger it has no event that would exercise it pre-merge, so verification of.github/workflows/rests on that issue's linter.