tool-bump.yml cannot do its job, and has reported success weekly since July
It has never opened a single PR:
$ gh pr list --state all --limit 100 --jq '.[] | select(.headRefName|startswith("bot/"))'
(nothing — no bot/* PR has ever existed in this repo)
Not because nothing was stale. Because the push is rejected. From a dispatched run today
(32273522116), the
first stale pin it reached:
Switched to a new branch 'bot/actionlint-1.7.12'
[bot/actionlint-1.7.12 e542809] chore(ci): bump actionlint to 1.7.12 (bot)
1 file changed, 2 insertions(+), 2 deletions(-)
! [remote rejected] bot/actionlint-1.7.12 -> bot/actionlint-1.7.12
(refusing to allow a GitHub App to create or update workflow `.github/workflows/ci.yml`
without `workflows` permission)
error: failed to push some refs
GITHUB_TOKEN cannot push changes to files under .github/workflows/, and no permissions:
setting can grant it. GitHub's workflow-syntax reference lists every available key — actions,
checks, contents, pull-requests, … — and there is no workflows among them. The workflow
scope exists only for a PAT or a GitHub App token.
Why nobody noticed
Every pin tool-bump.yml watched was current, every week, so it never reached open_pr. The run
went green each Monday on having found nothing to do — which is indistinguishable, from the outside,
from a watcher that works.
That is this program's signature defect: a check that reports success without ever having
executed the thing it exists to do. It is the same shape as pithead #1048, #1064 and #1128.
Scope: seven of nine pins are unreachable this way
| pin |
lives in |
pushable by GITHUB_TOKEN? |
| shellcheck, shfmt, actionlint, diff-cover |
.github/workflows/ci.yml |
no |
| gitleaks, zizmor |
.github/workflows/security.yml |
no |
| lychee |
.github/workflows/links.yml |
no |
| jq, kcov |
tests/coverage.sh |
yes |
xmrig-bump.yml is not affected — it edits rigforge.sh. Its push path is nonetheless
untested, for the same reason: the XMRig pin has been current every week, so it has never
pushed either. Worth keeping in mind before trusting it on the day it matters.
And #373 made the symptom worse, on purpose
Before #374 the pins were current so the run went green. Now five are stale, so the run goes red
every Monday at the first push. That is more honest, and it is also noise the operator will mute
if it is left. It needs fixing now, not filing.
Fix
Report-only, one tracking issue — the same mechanism pithead just adopted
(#1128 /
PR #1143). It works for every pin
regardless of where it lives, needs no new credential, and is a shorter file than what is there now.
The alternative — a PAT or GitHub App token with the workflow scope, stored as a secret — buys
back the "the new tool runs its own check on its own PR" property. That property is genuinely nice
and it is why the workflow was written this way. But it has never once actually happened, and
paying for it with a long-lived high-privilege credential that can rewrite this repo's CI is a poor
trade for a repo whose whole supply-chain posture is SHA-pinned actions and least-privilege tokens.
Recommendation: report-only here; keep xmrig-bump.yml's PR flow, since XMRig is the one pin where
a build-verified bump is worth having and its path is not blocked.
tool-bump.ymlcannot do its job, and has reported success weekly since JulyIt has never opened a single PR:
Not because nothing was stale. Because the push is rejected. From a dispatched run today
(32273522116), the
first stale pin it reached:
GITHUB_TOKENcannot push changes to files under.github/workflows/, and nopermissions:setting can grant it. GitHub's workflow-syntax reference lists every available key —
actions,checks,contents,pull-requests, … — and there is noworkflowsamong them. Theworkflowscope exists only for a PAT or a GitHub App token.
Why nobody noticed
Every pin
tool-bump.ymlwatched was current, every week, so it never reachedopen_pr. The runwent green each Monday on having found nothing to do — which is indistinguishable, from the outside,
from a watcher that works.
That is this program's signature defect: a check that reports success without ever having
executed the thing it exists to do. It is the same shape as pithead #1048, #1064 and #1128.
Scope: seven of nine pins are unreachable this way
.github/workflows/ci.yml.github/workflows/security.yml.github/workflows/links.ymltests/coverage.shxmrig-bump.ymlis not affected — it editsrigforge.sh. Its push path is nonethelessuntested, for the same reason: the XMRig pin has been current every week, so it has never
pushed either. Worth keeping in mind before trusting it on the day it matters.
And #373 made the symptom worse, on purpose
Before #374 the pins were current so the run went green. Now five are stale, so the run goes red
every Monday at the first push. That is more honest, and it is also noise the operator will mute
if it is left. It needs fixing now, not filing.
Fix
Report-only, one tracking issue — the same mechanism pithead just adopted
(#1128 /
PR #1143). It works for every pin
regardless of where it lives, needs no new credential, and is a shorter file than what is there now.
The alternative — a PAT or GitHub App token with the
workflowscope, stored as a secret — buysback the "the new tool runs its own check on its own PR" property. That property is genuinely nice
and it is why the workflow was written this way. But it has never once actually happened, and
paying for it with a long-lived high-privilege credential that can rewrite this repo's CI is a poor
trade for a repo whose whole supply-chain posture is SHA-pinned actions and least-privilege tokens.
Recommendation: report-only here; keep
xmrig-bump.yml's PR flow, since XMRig is the one pin wherea build-verified bump is worth having and its path is not blocked.