Give the lock-file chore a button, and a failure that names it - #61
Merged
Conversation
`Testcontainers` 4.13.0 resolves `SSH.NET` 2025.1.0, which is GHSA-q939-rpr3-3284, high severity: ScpClient's recursive download writes wherever a malicious server's filenames point. Every restore has been reporting it as NU1903, on both target frameworks. It is a test-only path and this repository does not treat warnings as errors, so nothing was failing -- it was just being printed and ignored. Patched in 2026.0.0, and 4.13.0 is Testcontainers' own latest release, so there is nothing upstream to wait for. Raised by referencing it directly from Healthie.Tests.Unit rather than by turning on CentralPackageTransitivePinningEnabled. That switch pins one version of every transitive package across the solution, which collides with the per-target-framework Microsoft.Extensions.* versions this file deliberately keeps apart: enabling it fails restore with 34 NU1109 downgrade errors. Verified both ways round. `dotnet restore --locked-mode` and `dotnet build -c Release` now finish with no warnings at all, where they previously printed two.
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. 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 restore is named and, on failure, says which workflow to run and on which branch. NU1004 does not mention the fix itself. - The constraint is written beside the nuget ecosystem in dependabot.yml. 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. Making it automatic needs a PAT or GitHub App key, which these repositories avoid by design. Verified on LakeWright.NET: green end to end against two live Dependabot branches, and it correctly declined to commit when the locks already matched.
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.
Dependabot bumps failed repeatedly 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 the 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. These repositories store no such credential deliberately. 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.
Verified
Shipped and exercised on
LakeWright.NETfirst: the workflow ran green end to end against two live Dependabot branches, and correctly declined to commit when the lock files already matched.