Give the lock-file chore a button, and a failure that names it - #72
Merged
Conversation
Dependabot edits Directory.Packages.props but cannot rewrite packages.lock.json: the CentralTransitive entries have to be resolved by NuGet rather than pattern-matched. So every NuGet bump lands with stale lock files and dies at `dotnet restore --locked-mode` with NU1004, before anything is built. That happened to four PRs this week and each one was fixed by hand. Three changes, none of which give a bot write access: - `Refresh lock files`, a workflow_dispatch job that regenerates the lock files on a named branch, proves the result with `--locked-mode` and a Release build, and commits only `**/packages.lock.json`. `contents: write` is scoped to that one job. - CI's restore step is named and, on failure, says which workflow to run and on which branch. NU1004's own text does not mention the fix. - The constraint is written down beside the nuget ecosystem in dependabot.yml, where the next person meets it. Deliberately a button rather than an automatic push on every Dependabot PR: a push made with GITHUB_TOKEN does not re-trigger workflows, so an automatic version would commit the fix and leave the required checks pinned to the superseded commit -- one stall traded for another. Making it automatic needs a PAT or a GitHub App key, and this repository stores no such credential on purpose.
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.
Four Dependabot PRs failed this week for the same reason, and each was fixed by hand.
The constraint
Dependabot edits
Directory.Packages.propsbut cannot rewritepackages.lock.json— theCentralTransitiveentries have to be resolved by NuGet, not pattern-matched. So every NuGet bump arrives with lock files naming the old versions and dies atdotnet restore --locked-modebefore anything builds:What this adds
Refresh lock files— aworkflow_dispatchjob. Give it a branch; it runs--force-evaluate, proves the result with--locked-modeand a Release build before committing, and commits only**/packages.lock.jsonby name.contents: writeis scoped to that single job, not the workflow.nugetecosystem independabot.yml.Why a button and not an automatic push
This was my first instinct and it does not work. A push made with
GITHUB_TOKENdoes not re-trigger workflows — by design, to prevent loops. An auto-commit bot would push the fix and leave the required checks pinned to the superseded commit: one stall traded for another.Making it automatic requires a PAT or a GitHub App private key. This repository stores no such credential deliberately —
SECURITY.mdstates publishing uses OIDC and "No publishing key is stored". Adding a long-lived write credential to automate a dependency chore is the wrong trade, so the human keeps the write and gets a button.