-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
CI: Add GitHub artifact attestations to package distribution #28273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI: Add GitHub artifact attestations to package distribution #28273
Conversation
427fe83
to
e28c1f4
Compare
@@ -79,7 +79,7 @@ repos: | |||
- id: yamllint | |||
args: ["--strict", "--config-file=.yamllint.yml"] | |||
- repo: https://github.com/python-jsonschema/check-jsonschema | |||
rev: 0.28.1 | |||
rev: 0.28.4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without this pre-commit
hook update, pre-commit
will fail as attestation
is a newer permissions
key. To keep this atomic I'm only updating this hook instead of all of them.
updates: - [github.com/python-jsonschema/check-jsonschema: 0.28.1 → 0.28.4](python-jsonschema/check-jsonschema@0.28.1...0.28.4)
* Add generation of GitHub artifact attestations to built sdist and wheel before upload. c.f.: - https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/ - https://docs.github.com/en/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds
e28c1f4
to
a5e6e93
Compare
This of course doesn't run unless we're tagging a release. Does it make sense to have a separate job that always runs to do the attestation? Or is that overkill? |
@QuLogic My understanding from scikit-hep/pyhf#2473 is that while there's nothing wrong with creating attestations for every run of the CI, there could value in keeping the number of attestations to a human readable number that just correspond to releases. As there doesn't seem to be a way to delete attestation records from GitHub I would advocate having attestations be 1-to-1 with published artifacts. |
I think starting with just releases is the right call. |
Example of a release of Awkward Array with signed artifacts, and how from a maintainer perspective keeping a clean visual list of release-only attestations would be nice: |
… package distribution
…273-on-v3.9.x Backport PR #28273 on branch v3.9.x (CI: Add GitHub artifact attestations to package distribution)
PR summary
This PR is related to scientific-python/summit-2024#9 so cc @QuLogic for review. c.f. scikit-hep/pyhf#2473 for reference.
PR checklist