chore(deps): actions: bump the all-actions group across 1 directory with 2 updates - #825
Conversation
…ith 2 updates Bumps the all-actions group with 2 updates in the / directory: [jdx/mise-action](https://github.com/jdx/mise-action) and [github/issue-metrics](https://github.com/github/issue-metrics). Updates `jdx/mise-action` from 4.2.1 to 4.2.5 - [Release notes](https://github.com/jdx/mise-action/releases) - [Changelog](https://github.com/jdx/mise-action/blob/main/CHANGELOG.md) - [Commits](jdx/mise-action@dad1bfd...3c2e0cf) Updates `github/issue-metrics` from 5.0.0 to 5.0.1 - [Release notes](https://github.com/github/issue-metrics/releases) - [Commits](github-community-projects/issue-metrics@df8c49d...61084fa) --- updated-dependencies: - dependency-name: jdx/mise-action dependency-version: 4.2.5 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: all-actions - dependency-name: github/issue-metrics dependency-version: 5.0.1 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: all-actions ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
scottschreckengaust
left a comment
scottschreckengaust
left a comment
There was a problem hiding this comment.
1. Verdict
Approve with nits. Both new pins are authentic full-SHA pins whose trailing version comments I verified against the upstream tag -> commit mapping; the bump is applied to every occurrence in the tree (7/7 jdx/mise-action, 2/2 github/issue-metrics) with no stale pin left behind; no new permission requirements; and all required checks are green at this head SHA. The nits below are supply-chain hygiene follow-ups (one of which is a real gap in our enforcement, not in this PR) and should be filed as issues rather than blocking a dependabot bump.
Method disclosure (read this before trusting any claim below). I did not run
mise run build, jest, pytest,tsc, orcdk synth— the review worktree has nonode_modules/oragent/.venv/and installs were out of scope. Everything about repo behavior is static reasoning plus read-onlygit/ghqueries against upstream. The one piece of execution evidence I rely on is GitHub's own CI on this head SHA (see §6).
2. Vision alignment
Passes. This is CI supply-chain maintenance, and it lands squarely on the bounded blast radius tenet: the substantive upstream change (mise-action v4.2.5) is a retry wrapper around mise binary downloads, which reduces spurious red on the control plane's own build path without loosening any gate. Nothing here touches admission, orchestration, memory, policy, HITL gates, or cost limits. No tenet is traded, so no ADR is owed.
One alignment detail worth stating explicitly because it is easy to misread as a gap: mise-action v4.3.0 shipped 2026-08-24 and is not in this PR. That is .github/dependabot.yml's cooldown: default-days: 7 doing exactly its job — at PR-open time (2026-08-28) v4.3.0 was 4 days old and correctly withheld, while v4.2.5 (2026-08-13) and issue-metrics v5.0.1 (2026-08-20) had both aged past the window. Expect a follow-up bump; that is the config working, not drift.
3. Blocking issues
None.
Because this is the class of PR where the pin is the entire security boundary, here is the verification, so a future reader does not have to redo it:
uses: |
claimed | upstream refs/tags/<v> -> commit |
match |
|---|---|---|---|
jdx/mise-action@3c2e0cf82a5b2e5249f0d3635a4d83d0ae861518 |
# v4.2.5 |
3c2e0cf82a5b2e5249f0d3635a4d83d0ae861518 (chore: release v4.2.5 (#598), 2026-08-13) |
yes |
github/issue-metrics@61084fa9599a62c7821f06602e180a42d1c7a205 |
# v5.0.1 |
61084fa9599a62c7821f06602e180a42d1c7a205 (2026-08-20) |
yes |
Both are 40-hex commit SHAs (not tags, not branches), and neither comment overstates the pin — the specific failure mode where a truthful-looking # vX.Y.Z hides an unrelated SHA is not present here. Note for the second row: the commit message at that SHA is chore(deps): bump the dependencies group with 3 updates (#812) rather than a release commit — that is just where upstream cut the v5.0.1 tag, and refs/tags/v5.0.1 resolves to it. Not a discrepancy.
Consistency (focus item b) — verified complete. grep -rn 'jdx/mise-action' across the head tree returns exactly seven uses: lines (build.yml:242, dead-code-pr.yml:36, deploy.yml:237, integ.yml:210, security-pr.yml:47, security.yml:51, upgrade-main.yml:48), all at the new SHA with the # v4.2.5 comment; issue-metrics returns exactly two (monthly-repo-metrics.yml:44 and :57), both at the new SHA. The old SHAs dad1bfd3… / df8c49d2… appear nowhere in the tree, including docs and the Starlight mirror. No split-version state.
Permissions (focus item c) — no change required. I diffed action.yml at both pins for both actions:
jdx/mise-action: the only interface change is a new optional inputexport_path(default"true") plus a rewordedenvdescription. No new required input, no newpermissions:need.github_tokenalready defaulted to${{ github.token }}, and the tools it fetches are public releases.github/issue-metrics:action.ymlis byte-identical between v5.0.0 and v5.0.1.monthly-repo-metrics.ymlkeeps its deny-all top-level block with a job-scopedissues: write/pull-requests: read, which still matches what the action does (the v5.0.1 changelog's discussion-related fixes are irrelevant here — bothSEARCH_QUERYvalues areis:issue/is:pr, so nodiscussions: readis needed).
Base drift — checked, does not invalidate the PR. Merge-base is 780161b9; origin/main is now 4da0a1fa. The only main-side change under .github/ since the merge-base is security-pr.yml (+34/-8, adding the ratcheted silent-success-masking scan, #756), which shifted the Install mise line from 47 to 52. Main's two hunks are the header comment block and the range-resolution step below the mise step, so they do not overlap this PR's one-line hunk — the bump still lands on merge, consistent with GitHub reporting MERGEABLE (mergeStateStatus: BLOCKED is the review/queue gate, not a conflict). Main's other recent commit (#844, browserslist re-resolve) is unrelated to this diff.
4. Non-blocking suggestions / nits
N1 — We enforce that actions are pinned, but nothing enforces that the version comment tells the truth. mise run security:gh-actions is zizmor --offline .github, and --offline is deliberate (mise.toml:198). zizmor's unpinned-uses will fail a floating tag, but an offline run cannot resolve # v4.2.5 back to a SHA — so a pin carrying a wrong or malicious SHA under a plausible comment passes CI clean. Today that gap is closed only by a human doing the gh api repos/<owner>/<repo>/git/ref/tags/<v> lookup I did in §3. This repo already has the right home for that: add a check:action-pin-comments task to the drift-prevention list (mise.toml:113-122, alongside check:transitive-pin-sync) that walks every uses: <o>/<r>@<sha> # <tag> and asserts the tag resolves to that SHA. Online-only, so it belongs in drift-prevention, not in the offline zizmor run. Worth an issue (P2). Out of scope for a dependabot PR.
N2 — The issue-metrics half of this bump is a runtime no-op, and its SHA pin is largely decorative. action.yml at both pins (and on upstream main today) is:
runs:
using: "docker"
image: "docker://ghcr.io/github-community-projects/issue_metrics:v4"So the code that actually executes in monthly-repo-metrics.yml is whatever the mutable :v4 container tag resolves to at run time — identical before and after this PR. Two consequences: (a) we get none of the advertised v5.0.1 fixes deterministically, and (b) our 40-hex pin does not pin the executed artifact, which is worth knowing given the job holds issues: write. Also note the tag says v4 while the action is at v5.0.1 — upstream staleness, not ours. Remedy options for a follow-up issue: reference the image digest directly (uses: docker://ghcr.io/github-community-projects/issue_metrics@sha256:…), or keep the action reference and record the accepted residual risk next to the step. Pre-existing; not introduced by this PR — I am not asking dependabot to fix it.
N3 — github/issue-metrics is now a redirect. The repo has been transferred to github-community-projects/issue-metrics (gh api repos/github/issue-metrics -> full_name: github-community-projects/issue-metrics). Resolution via redirect works today and dependabot faithfully rewrites whatever string is in the file, but referencing the canonical owner removes a dependency on GitHub's redirect surviving. Fold into the N2 issue.
N4 — Behavior change riding along in v4.2.1 -> v4.2.5, and why I concluded it is safe here. The range crosses v4.2.3, which restored mise's PATH propagation to subsequent steps via GITHUB_PATH and added the export_path input (default true). None of our workflows set export_path, so mise's shim/[env] _.path directories are now on PATH for later steps where under v4.2.1 they were not. Static reasoning that this does not shadow the pinned toolchain: mise.toml declares node = "22", and in all seven workflows Install mise runs before actions/setup-node (build.yml:241/246, dead-code-pr.yml:35/41, deploy.yml:236/242, integ.yml:209/215, security.yml:50/56, upgrade-main.yml:47/53; security-pr.yml has no setup-node). GITHUB_PATH entries are prepended in step order, so setup-node's entry lands on top and still wins — and every repo step invokes tooling through mise run … anyway, which resolves via mise's own env regardless of PATH. I could not execute this locally; the empirical confirmation is that build (agentcore) passed in 14m35s at this head SHA (§6), i.e. the new PATH behavior was exercised.
N5 — Hardening idea, pre-existing, do not change it in this PR. In deploy.yml the AWS role is assumed at line 231 (configure-aws-credentials) before the third-party mise-action runs at line 237; same shape in integ.yml (202 -> 210). Both jobs carry id-token: write. A compromised pin in that position executes with live AWS credentials already in the job environment. Swapping the order (install mise, then assume the role) shrinks that window at zero cost. This is exactly why the §3 pin verification is not ceremony. Pre-existing ordering, unchanged by this diff — file as its own issue.
N6 — Governance, for the record: not a blocker. There is no backing issue, and the branch is dependabot/github_actions/all-actions-6a02ed387a rather than (feat|fix|chore|docs)/<issue>-…. ADR-003's "No PRs without an Issue" is written for human and agent contributors; automated dependency PRs are a de facto standing exception here, with eight merged precedents (#290, #343, #397, #528, #592, #624, #625, #672) and a .github/dependabot.yml that the repo maintains deliberately (grouping, 7-day cooldown, Cedar-parity ignores). I am not raising this as a finding. I would suggest ADR-003 gain one sentence carving out bot dependency PRs so each reviewer stops re-litigating it.
5. Documentation
Nothing owed, nothing missing. No file under docs/guides/, docs/design/, docs/decisions/, or CONTRIBUTING.md is touched, so no Starlight mirror regeneration is required and there is no "Fail build on mutation" exposure from this diff. No env var, command, contract, or developer-flow change, so no AGENTS.md / README / package-doc update is owed. The # vX.Y.Z trailing comments are the documentation for a SHA pin, and both are accurate (§3). I confirmed the two stale-comment risks nearby are clean: monthly-repo-metrics.yml:2 still describes the workflow correctly, and .gitleaks.toml:101 mentions jdx/mise-action only as prose about digit runs in SHA pins — it carries no pin to drift.
Issue tracking: this PR needs no issue (N6). The three follow-ups I would file are N1 (pin-comment verification task), N2+N3 (mutable :v4 image behind the issue-metrics pin, plus canonical owner), and N5 (assume the AWS role after installing mise).
6. Tests & CI
No unit tests are added or expected — there is no testable code path in a workflow pin bump, and no */test/ tree is implicated.
Bootstrap synth-coverage: not applicable. The diff touches no CDK construct, stack, or handler and introduces no CloudFormation resource type, so cdk/src/bootstrap/policies/*.ts, resource-action-map.ts, BOOTSTRAP_VERSION, the regenerated artifacts, and the DEPLOYMENT_ROLES.md golden baseline are all correctly untouched (ADR-002 / #350 do not engage).
CI at d5f83b1 (queried, not run by me):
| check | conclusion |
|---|---|
build (agentcore) |
success (14m35s) |
Secrets, deps, and workflow scan |
success (19s) |
Dead-code detection (advisory) |
success |
Validate PR title |
success |
CodeQL |
skipped/neutral (no compiled-language change) |
auto-approve |
skipped (label-gated) |
I confirmed via gh api .../commits/d5f83b1/check-runs that these ran against this head SHA, not an earlier one. Two things follow. First, because pull_request events use the head ref's copy of the workflow, build and the security scan genuinely executed with mise-action@v4.2.5 — that is real execution evidence for N4, and it is the only such evidence in this review. Second, the passing Secrets, deps, and workflow scan includes security:gh-actions, so zizmor is satisfied that both uses: lines are hash-pinned — subject to the offline limitation in N1 (it validates that they are pinned, not that the comments are honest, which is why I resolved the tags by hand).
One forward-looking note: because the PR is behind main, the merge queue will re-run the required check using trunk's security-pr.yml, which now includes the ratcheted masking step added in #756. That step did not run on this PR's own copy. It scans only findings added since the base, and this diff adds nine YAML lines with no error handling, so I expect it to be a no-op — stated as expectation, not verified.
Test-coverage gap worth naming (the pr-test-analyzer dimension): nothing in-repo asserts pin-comment/SHA agreement. That is N1, and it is the one durable improvement this PR's subject matter suggests.
7. Review agents run
Nested agent dispatch was unavailable in this run. This review executed as a subagent inside a batch fan-out, which cannot spawn further agents, so I could not invoke the pr-review-toolkit agents (code-reviewer, silent-failure-hunter, type-design-analyzer, comment-analyzer, pr-test-analyzer). I did not run them and am not claiming their output. Instead I applied each rubric dimension inline, myself, one at a time. Please read the following as rubric-applied-inline, not agent-dispatched:
code-reviewer(guidelines/style/conventions) — applied inline. Pass. Both new lines keep the repo's established pin formuses: <owner>/<repo>@<40-hex> # v<semver>and preserve surroundingwith:blocks and indentation. Placement is correct per the AGENTS.md routing table (monorepo CI ->.github/workflows/); no package tree is implicated.silent-failure-hunter(error handling, swallowed exceptions, plausible-default fallbacks) — applied inline. Pass, and non-trivially so. No error-handling code is in the diff, but the dimension is genuinely in scope because v4.2.5's substantive change is a retry wrapper: it makes up to five attempts with a warning logged per retry, then still fails the step. Per upstream's release notes, checksum and minisign verification remain outside the retry loop and run only after a successful download, so integrity is not weakened and a hard failure is not converted into a plausible-looking success. That is the shape this repo's silent-success-masking rule wants. Verified from upstream release notes and theaction.ymlinterface diff, not by auditing the 7k-linedist/index.jsbundle — see the honesty note below.type-design-analyzer(new types, encapsulation, invariants) — genuinely out of scope. The diff introduces no type, class, interface, or schema; it is nine YAML scalar changes.comment-analyzer(comment accuracy vs code) — applied inline. Pass, and this is the highest-value dimension for this diff. On a SHA pin the trailing comment is the security-relevant assertion, so I resolved both against upstream rather than eyeballing them (§3 table). I also checked the two nearby unchanged comments that could have gone stale (monthly-repo-metrics.yml:2,.gitleaks.toml:101) — both still accurate.pr-test-analyzer(coverage of failure paths) — applied inline. No test is possible or expected; CI green at the head SHA is the evidence (§6). The real finding from this dimension is the missing pin-comment verification check, raised as N1./security-review— skill invoked (skills load in-context, so this one was available), with a caveat, and it produced no findings. The skill's harness collected git state from the operator'smaincheckout rather than the PR worktree and therefore saw an empty diff, so its automated pass was vacuous; I re-applied its rubric by hand against/tmp/…/diffs/pr825.diff. Result: no HIGH or MEDIUM findings newly introduced by this PR. Pin authenticity verified (§3). The mutable:v4container tag (N2) and the assume-role-before-third-party-action ordering (N5) are both pre-existing and byte-identical at the old pin, so under the skill's own "do not report existing security concerns" rule they are not findings — I surface them as nits instead. I also considered whether the restoredGITHUB_PATHexport (N4) gives a fork PR a new capability via[env] _.pathinmise.toml: it does not, because a fork PR that can editmise.tomlcan already have CI execute repo-definedmise runtasks, so no privilege is gained.
Honest limits. I did not audit mise-action's bundled dist/index.js (+6953/-1180 across the range) or the issue_metrics:v4 container contents. My assurance for those rests on the verified SHA-to-tag mapping, upstream release provenance, and dependabot's 7-day cooldown — not on reading the shipped bundle. N1 and N2 are the structural mitigations.
8. Human heuristics
- Proportionality — pass. Nine changed lines for two patch bumps. No abstraction, no new machinery, nothing accreted.
- Coherence — pass. The change belongs in
.github/workflows/, uses the same pin vocabulary as every otheruses:in the repo, and leaves the tree single-versioned for both actions (§3). The parallel structure across seven files is substantive, not copy-paste padding — each is a real call site. - Clarity — pass.
@<sha> # <tag>communicates both the immutable reference and the human-readable version, and both halves are true. No magic value belongs incontracts/constants.jsonhere; action pins are correctly workflow-local. - Appropriateness — pass with one caveat already filed. Maintainable by this team, and integration behavior was checked against the real upstream artifacts (
action.ymlat both SHAs, tag refs, repo redirect) rather than assumed from the changelog. The caveat is N2: forissue-metrics, the real API behavior is "runs a mutable container tag," which means the pin buys less than it appears to — exactly the AI001 failure mode of trusting the declared interface over the observed one, caught here by readingaction.ymlinstead of the release notes.
1 participant
Bumps the all-actions group with 2 updates in the / directory: jdx/mise-action and github/issue-metrics.
Updates
jdx/mise-actionfrom 4.2.1 to 4.2.5Release notes
Sourced from jdx/mise-action's releases.
... (truncated)
Changelog
Sourced from jdx/mise-action's changelog.
... (truncated)
Commits
3c2e0cfchore: release v4.2.5 (#598)9dda395fix: retry mise downloads after transient failures (#597)9d2b311chore(deps): update github/codeql-action action to v4.37.6 (#593)4213fbbchore(deps): update jdx/mise-action action to v4.2.4 (#594)672dbd2chore(deps): update zizmorcore/zizmor-action action to v0.6.2 (#595)5159765chore(deps): lock file maintenance (#592)c75b4f6chore(deps): update jdx/mise-action action to v4.2.3 (#590)367cc0dchore(deps): update github/codeql-action action to v4.37.3 (#589)90e6e66chore(deps): update zizmorcore/zizmor-action action to v0.6.1 (#591)7350bb8chore(deps): lock file maintenance (#588)Updates
github/issue-metricsfrom 5.0.0 to 5.0.1Release notes
Sourced from github/issue-metrics's releases.
Commits
61084fachore(deps): bump the dependencies group with 3 updates (#812)89c9701chore(deps): bump astral-sh/setup-uv from 9.0.0 to 10.0.0 (#813)8a73a86chore(deps): bump actions/stale from 10.4.0 to 11.0.0 (#807)fc3689bchore(deps): bump the dependencies group across 1 directory with 2 updates (#...ed13968chore(deps): bump the dependencies group with 5 updates (#809)ad212eechore(deps): bump the dependencies group with 6 updates (#806)f813595chore(deps): bump the dependencies group with 5 updates (#801)3bb1e85chore(deps): bump astral-sh/setup-uv from 8.3.2 to 9.0.0 (#802)a98bcbfrefactor: port discussions.py off requests onto PyGithub GraphQL (#800)f184502fix: repair dead discussion mentor-counting branch (#776)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions