fix: accept GitHub tag update rules without branch parameters - #40
Merged
Merged
Conversation
Signed-off-by: abrichr <richard.abrich@mldsai.com>
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.
GitHub returns a tag update restriction as
{"type":"update"}, even when the request suppliesupdate_allows_fetch_and_merge:false. The current validator rejects that readback, which prevents an otherwise protected release from reaching admission.Accept the two exact tag-rule encodings: the bare update rule and the existing explicit Boolean-false form. GitHub documents the parameter as an optional branch setting. Neither form grants an update bypass. The creation App identity, active tag scope, deletion and non-fast-forward restrictions, and empty immutability bypass list remain required. Unknown fields and non-Boolean false values still fail.
The admission adapter compares the retained rule to the current API response without adding a missing field. The staging digest therefore continues to bind the observed bytes. This change doesn't alter old signed objects or make an existing GitHub release immutable.
Validation: 38 focused test methods pass, including 55 new positive and negative subcases. Independent review also checked the real ruleset readbacks through the runtime validator and JSON Schema. The retained rule bytes and their digest remain unchanged. Required PR CI passed. The unchanged issuer also fetched current control metadata and both artifact files from GitHub and PyPI. It accepted the raw bare-update staging, then refused a changed retained-rule representation against the live response.
References: GitHub REST rule definitions and Restrict updates.