deps: Bump System.ValueTuple from 4.5.0 to 4.6.2 - #58
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
Collaborator
|
@dependabot rebase |
Contributor
Author
|
Looks like this PR is already up-to-date with main! If you'd still like to recreate it from scratch, overwriting any edits, you can request |
Collaborator
|
@dependabot recreate |
dependabot
Bot
force-pushed
the
dependabot/nuget/Build/Dependencies/System.ValueTuple-4.6.2
branch
from
August 21, 2026 07:20
7a51ef8 to
f4644a0
Compare
Collaborator
|
@dependabot rebase |
dependabot
Bot
force-pushed
the
dependabot/nuget/Build/Dependencies/System.ValueTuple-4.6.2
branch
from
August 21, 2026 12:50
f4644a0 to
42aa50c
Compare
Collaborator
|
@dependabot rebase |
--- updated-dependencies: - dependency-name: System.ValueTuple dependency-version: 4.6.2 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/nuget/Build/Dependencies/System.ValueTuple-4.6.2
branch
from
August 21, 2026 14:55
42aa50c to
8bdf9c0
Compare
Collaborator
|
/validate |
mvaneijken
added a commit
that referenced
this pull request
Aug 31, 2026
) * Make Dependabot bumps mergeable without loosening the pins from #24 Every open Dependabot pull request failed validation, and none of the four causes was the hash pinning itself - that gate worked exactly as intended. A bump has to move three files, and Dependabot writes one of them: Build/Dependencies/Dependencies.csproj Dependabot OmadaWeb.PS/DependencyLock.psd1 dependency-lock-sync.yml, by hand Build/Dependencies.psd1 (SBOM) nothing at all So: - The lock sync was workflow_dispatch-only and nobody ran it. It now sweeps every open Dependabot pull request weekly. To keep a write-scoped token away from code on the branch under review it checks out two trees and runs the script from the default branch against the pull request branch as data, through -RepositoryRoot. The manual single-branch run is still there. - -Refresh never updated the SBOM inventory, so the versions it reports drifted from the versions actually loaded and the unit test failed even once the hashes were right. It now refreshes both, and -Check reports the drift. - -Refresh reported the very drift it exists to resolve as a problem and then exited non-zero, so the workflow could never reach its commit step. Manifest and SBOM drift are now informational under -Refresh and fatal under -Check. - Dependabot kept proposing bumps that cannot be taken. #55, #58 and part of #70 moved members of the System.Text.Json closure on their own; the module loads those with Assembly.LoadFrom, which applies no binding redirects, so the versions loaded have to be the ones the pinned System.Text.Json resolves. They are now ignored for version updates, as Legacy/Selenium already was, and still raise advisories. -Check asserts each closure member has an ignore rule, so the lock and the policy cannot drift apart. The guarantee from #24 is unchanged: -Check still fails the build on any mismatch, and syncing does not revalidate a pull request - PR Validation is triggered by /validate, so a maintainer still validates and merges. * Address review feedback and harden the sweep Tests: the sandbox tests hard-coded Newtonsoft.Json 13.0.4, so a legitimate bump would have broken tests that are really about "these two files disagree". Versions now come from the lock at runtime, and the doctoring asserts the text it replaces was actually there - a renamed field would otherwise leave the test passing while exercising nothing. Workflow: pull.head.repo is null when a head repository has been deleted, which would have thrown and taken the whole sweep with it; guarded. And the branch name now reaches the commit step through the environment instead of being interpolated into the script, so a branch name cannot become code. * Read the ignore list whatever its YAML quoting, and reuse the manifest cache Three findings from the second review pass, all in Get-IgnoredDependencyName and the -Refresh loop. The parser only stripped double quotes. YAML scalars may be double-quoted, single-quoted or bare and all three mean the same string, so reformatting dependabot.yml would have made the closure check read 'System.Buffers' including its quotes, not match the package id, and fail the build over nothing. Quotes are now stripped rather than matched, for both the directory and the dependency-name, and a test rewrites the whole file into the other two styles and asserts the check still passes. A directory line now also ends any ignore list already being read. The ordering in this file never produced that case, but scoping ignore rules to the right manifest is the whole point of the function. -Refresh re-parsed each manifest once per artefact although the offline checks had already built the per-manifest cache. Reuses it. * Assert the ignore rules, not the quotes around them The previous commit taught -Check that YAML scalars may be double-quoted, single-quoted or bare, and then left the two policy tests matching a literal dependency-name: "X". So the tests contradicted the parser: a reformatting of dependabot.yml that -Check accepts would have failed them. Both now go through a Test-IgnoreRule helper that accepts any of the three quotings, which is what the rule actually means. -Refresh read the SBOM inventory unguarded. A missing file was already reported by the offline checks, but the bare Get-Content threw first and replaced that message with a file-not-found. Guarded, so the run ends with the message that explains it. And the "every pin already matches" line no longer prints when problems were reported - it sat directly above the failure and contradicted it. * Remove ignore rules by rule, not by their quoting, in the sandbox tests The two tests that strip a rule from a sandbox config to prove the check fires still matched the literal dependency-name: "System.Memory". That is the same contradiction the previous commit fixed on the asserting side: a reformatting of dependabot.yml that -Check accepts would have left these tests removing nothing, so they would have gone on to assert a failure that no longer had a cause - passing for the wrong reason, or failing for one. Both now go through Remove-IgnoreRule, which matches any of the three YAML quotings and asserts the rule was actually there before removing it. The matching pattern is shared with Test-IgnoreRule so the two cannot drift. * Refuse an SBOM that mirrors one lock artefact twice Get-InventoryComponent keys components by LockId and silently kept the last of any duplicates, so a second component mirroring the same artefact would have been dropped from the drift check while -Refresh still rewrote both. A stale version in the shadowed component could then ship unnoticed - a hole in a file whose whole purpose is failing closed. The lock already refuses ambiguous ids. The SBOM now does too.
Contributor
Author
|
Looks like System.ValueTuple is no longer being updated by Dependabot, so this is no longer needed. |
dependabot
Bot
deleted the
dependabot/nuget/Build/Dependencies/System.ValueTuple-4.6.2
branch
August 31, 2026 13:19
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.
Updated System.ValueTuple from 4.5.0 to 4.6.2.
Release notes
Sourced from System.ValueTuple's releases.
No release notes found for this version range.
Commits viewable in compare view.