Conversation
Downgrades Serilog.AspNetCore in Api.csproj without touching any packages.lock.json, reproducing the exact NU1004 Dependabot produces. Used to verify the commit/push/re-trigger path of refresh-lockfiles.yml. Not for merge.
Dependabot updates only the lock file of the project it edited; Api and Tests reference Application/Infrastructure transitively and go stale, which fails ci.yml's restore --locked-mode with NU1004.
Dependabot updates only the lock file of the project it edited; Api and Tests reference Application/Infrastructure transitively and go stale, which fails ci.yml's restore --locked-mode with NU1004.
thomas-lg
added a commit
that referenced
this pull request
Aug 31, 2026
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.
Dependabot updates only the lock file of the project it edited; Api and Tests reference Application/Infrastructure transitively and go stale, which fails ci.yml's restore --locked-mode with NU1004.
thomas-lg
added a commit
that referenced
this pull request
Aug 31, 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.
Owner
Author
|
Closing — throwaway self-test PR. It did its job: it exposed that the commit/push/re-trigger half of |
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.
Throwaway PR to verify the commit/push/re-trigger path of
refresh-lockfiles.yml, which my earlier run never reached (it hit 'already consistent'). Will be closed and the branch deleted.