ci(release): bring the release pipeline up to parity with provide-foundation - #4
Merged
Merged
Conversation
…ndation Both failures below were found by provide-foundation's v0.4.3 release, which reached PyPI and left its GitHub release with no artifacts and no signatures. This repository carries identical code and would do the same on its next tag. Sigstore: both signing steps pinned gh-action-sigstore-python at v3.0.0, from July 2024, which installs `sigstore ~= 3.0`. sigstore-python 3.x bundles a TUF root that can no longer verify Sigstore's production root: tuf.api.exceptions.UnsignedMetadataError: root was signed by 0/3 keys raised from TrustedRoot.production() before anything is signed. Signing does not degrade, it aborts. v3.1.0 moved the action to sigstore-python 4.x for Rekor v2; v3.5.0 is current, and rekor-version still defaults to 1 in the action's 3.x series, so bundle format and the dist/*.sigstore.json upload glob are unaffected. SBOM: the dependency-closure check read every Requires-Dist and demanded each name appear, skipping only lines containing the literal "extra ==" -- a hand-rolled evaluation of one marker, blind to every other. Markers are now evaluated with packaging, against an empty extra, under the venv's own interpreter, since that is the environment the document describes. This project declares no conditional dependency today, so the check has never misfired here. It is fixed now rather than when the first one is added, which is how provide-foundation found it. Verified against a fresh `uv build`: "SBOM describes provide-foundry 0.4.0 with 57 dependencies", root component and purl correct.
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
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.
Both failures below were found by provide-foundation's v0.4.3 release, which reached PyPI and left its GitHub release with no artifacts and no signatures. This repository carries identical code and would do the same on its next tag — which matters right now, because 0.4.1 needs cutting to ship #3.
Sigstore — signing aborts
Both signing steps pinned
gh-action-sigstore-pythonat v3.0.0 (July 2024), which installssigstore ~= 3.0. sigstore-python 3.x bundles a TUF root that can no longer verify Sigstore's production root:raised from
TrustedRoot.production()before anything is signed. It does not degrade — it aborts, which is why v0.4.3 ended up with an empty release page.v3.1.0 moved the action to sigstore-python 4.x for Rekor v2; v3.5.0 is current.
rekor-versionstill defaults to 1 in the action's 3.x series, so bundle format and thedist/*.sigstore.jsonupload glob are unaffected. Still pinned by SHA, with a note at both call sites.SBOM — a marker matched as a substring
The closure check demanded every
Requires-Distname appear in the SBOM, skipping only lines containing the literal"extra =="— a hand-rolled evaluation of one marker, blind to every other. Markers are now evaluated withpackaging, against an emptyextra, under the venv's own interpreter, since that is the environment the document describes.packagingis installed after generation so it is not published as a component.This project declares no conditional dependency today, so the check has never misfired here. It is fixed now rather than when the first one is added — which is exactly how provide-foundation found it, mid-release.
Verified
./scripts/sbom_from_wheel.shagainst a freshuv build:packagingdoes appear among the 57 — genuinely, as a transitive dependency. The SBOM is generated before the script installs it, so by construction that is not pollution from this change; provide-foundation's came back with 3 components and nopackaging.