fix(ci): make refresh-lockfiles re-trigger checks that actually run - #101
Merged
Merged
Conversation
The re-trigger step was wrong in two ways, both found by self-testing the workflow against a deliberately stale branch (PR #100): 1. A GITHUB_TOKEN push doesn't leave runnable checks. GitHub creates the pull_request runs but parks them as 'action_required', awaiting manual approval, so the required checks keep reporting their pre-fix state. 2. gh pr update-branch was the only mitigation, and it no-ops with 'PR branch already up-to-date' whenever the PR isn't behind main -- which left the PR with no runnable checks at all, and unmergeable. Closing and reopening the PR raises a fresh pull_request event that runs without approval; verified by hand on #100, where it moved the parked runs to in_progress and backend then passed. update-branch is kept first, for main's strict up-to-date rule, and made non-fatal since no-op is a valid outcome. The refresh itself was correct throughout: it committed exactly the two stale lock files (Api directly, Tests transitively) and turned the red NU1004 PR green.
Close/reopen from inside the workflow doesn't help: the runs' triggering actor is still github-actions[bot], so they stay parked as action_required. Verified on PR #100 -- a bot close/reopen left CI parked, while the identical close/reopen from a user token started it at once. GITHUB_TOKEN can't approve its own runs either. So stop pretending. The workflow still does the valuable part (restore, guard, commit, push, update-branch), then detects whether the checks are parked and prints the single command that finishes it, in both the job summary and a warning annotation. Needs actions: read to list run states. README no longer claims the workflow completes the loop unattended, and says what closes it.
thomas-lg
added a commit
that referenced
this pull request
Sep 13, 2026
…101) * fix(ci): make refresh-lockfiles re-trigger checks that actually run The re-trigger step was wrong in two ways, both found by self-testing the workflow against a deliberately stale branch (PR #100): 1. A GITHUB_TOKEN push doesn't leave runnable checks. GitHub creates the pull_request runs but parks them as 'action_required', awaiting manual approval, so the required checks keep reporting their pre-fix state. 2. gh pr update-branch was the only mitigation, and it no-ops with 'PR branch already up-to-date' whenever the PR isn't behind main -- which left the PR with no runnable checks at all, and unmergeable. Closing and reopening the PR raises a fresh pull_request event that runs without approval; verified by hand on #100, where it moved the parked runs to in_progress and backend then passed. update-branch is kept first, for main's strict up-to-date rule, and made non-fatal since no-op is a valid outcome. The refresh itself was correct throughout: it committed exactly the two stale lock files (Api directly, Tests transitively) and turned the red NU1004 PR green. * fix(ci): report the approval gate instead of trying to defeat it Close/reopen from inside the workflow doesn't help: the runs' triggering actor is still github-actions[bot], so they stay parked as action_required. Verified on PR #100 -- a bot close/reopen left CI parked, while the identical close/reopen from a user token started it at once. GITHUB_TOKEN can't approve its own runs either. So stop pretending. The workflow still does the valuable part (restore, guard, commit, push, update-branch), then detects whether the checks are parked and prints the single command that finishes it, in both the job summary and a warning annotation. Needs actions: read to list run states. README no longer claims the workflow completes the loop unattended, and says what closes it.
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
1 participant
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.
Self-testing
refresh-lockfiles.yml(added earlier today in #86) against a deliberately stale branch turned up two bugs in its final step. My original verification run had hit the "lock files already consistent" path, so the commit/push/re-trigger half had never actually executed.What was wrong
GITHUB_TOKENpush doesn't leave runnable checks. I'd assumed it raised no events at all; what actually happens is GitHub creates thepull_requestruns and parks them asaction_required, awaiting manual approval. Either way the required checks keep reporting their pre-fix state.gh pr update-branchwas the only mitigation, and it silently no-ops. It reports✓ PR branch already up-to-datewhenever the PR isn't behindmain. That's the common case right after a merge — and it left the PR with no runnable checks at all, so it couldn't merge and nothing would ever re-run.The fix
Close and reopen the PR, which raises a fresh
pull_requestevent that runs without approval.update-branchis kept, first, formain's strict up-to-date rule, and made non-fatal since no-op is a legitimate outcome.Closing a Dependabot PR is normally its "don't recreate this update" signal; it's reopened within a second and then merged, so the update lands regardless. That tradeoff is noted in the step comment.
Evidence
On #100 — a branch with
Serilog.AspNetCoredowngraded inApi.csprojand the lock files deliberately untouched, reproducing Dependabot's exact NU1004:backendon the broken headApi+Testslock files, nothing elseaction_required— parked, never ranbackendafter re-triggerThe refresh logic itself was correct all along — it turned the red PR green. Only the re-trigger was broken.
Verified by dispatching this branch's version of the workflow via
--refbefore merging.