Context
.github/workflows/fix-dependabot-lockfile.yml regenerated pnpm-lock.yaml on Dependabot PRs (needed because Dependabot's pnpm catalog support is weak, so its lockfile updates mismatch and fail --frozen-lockfile + minimumReleaseAgeStrict).
It has been removed for now because, as written, it doesn't actually unblock the PR.
Why it was removed
- The fix commit doesn't re-run CI. The push used the default
secrets.GITHUB_TOKEN, and commits pushed with GITHUB_TOKEN do not trigger new workflow runs (GitHub's loop-prevention). So the regenerated lockfile is committed, but the Build/Tests/Security Audit jobs that failed on the mismatched lockfile never re-run — the PR stays red/stuck.
What a correct re-introduction needs
- A push identity that re-triggers workflows — a GitHub App installation token (preferred) or a fine-grained PAT stored as a Dependabot secret, used as
actions/checkout's token: and for the push. This is the core fix.
concurrency group keyed on github.head_ref (Dependabot rebases/force-pushes; overlapping runs race on git push).- Rebase before push (
git pull --rebase / --force-with-lease) so a branch that advanced mid-run doesn't fail the push.
timeout-minutes on the job.- Optionally narrow the trigger with
paths: (package.json / pnpm-workspace.yaml) so it doesn't run on Dependabot PRs that don't touch the lockfile.
Alternative
Fold the lockfile regeneration into the front of the main CI workflow (regenerate + commit as step 1, same actor guard) so later jobs in the same run use the fixed lockfile — sidesteps the cross-workflow re-trigger limitation without needing an App token.
See discussion for full analysis.
Context
.github/workflows/fix-dependabot-lockfile.ymlregeneratedpnpm-lock.yamlon Dependabot PRs (needed because Dependabot's pnpm catalog support is weak, so its lockfile updates mismatch and fail--frozen-lockfile+minimumReleaseAgeStrict).It has been removed for now because, as written, it doesn't actually unblock the PR.
Why it was removed
secrets.GITHUB_TOKEN, and commits pushed withGITHUB_TOKENdo not trigger new workflow runs (GitHub's loop-prevention). So the regenerated lockfile is committed, but theBuild/Tests/Security Auditjobs that failed on the mismatched lockfile never re-run — the PR stays red/stuck.What a correct re-introduction needs
actions/checkout'stoken:and for the push. This is the core fix.concurrencygroup keyed ongithub.head_ref(Dependabot rebases/force-pushes; overlapping runs race ongit push).git pull --rebase/--force-with-lease) so a branch that advanced mid-run doesn't fail the push.timeout-minuteson the job.paths:(package.json / pnpm-workspace.yaml) so it doesn't run on Dependabot PRs that don't touch the lockfile.Alternative
Fold the lockfile regeneration into the front of the main CI workflow (regenerate + commit as step 1, same actor guard) so later jobs in the same run use the fixed lockfile — sidesteps the cross-workflow re-trigger limitation without needing an App token.
See discussion for full analysis.