You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By clicking &ldq
8000
uo;Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Since it tracks mainline, we might run tests with this Action on a daily timer, just to make sure new changes will be compatible.
I'll point out that if the test runs in sigstore-python project it's not about "making sure changes are compatible" -- if you wanted to do that, you should have run the test in the infra projects, before merging the code.
The issue with testing here is that it pushes the responsibility to react to failures to sigstore-python: this project does not have a huge amount of developers willing to monitor tests like this... Maybe this does makes sense, but this is the compromise that would be made. We'll want to carefully evaluate what we want to test against -- some possible examples:
staging and prod only (status quo)
staging, prod and a local test setup running latest infra releases
staging, prod and a local test setup running every infra commit
My hunch is that the last option seems unlikely, but the second one might be interesting?
Description
The new Action at https://github.com/sigstore/scaffolding/tree/main/actions/setup-sigstore-env can setup containers within a Workflow run, and it can generate a trusted root (currently not signing config v0.02) and signing config to make it easy to use from the CLI.
It tracks mainline of the services Fulcio, Rekor, TSA, the new rekor-tiles, and provides a fakeoidc provider we might find useful.
Since it tracks mainline, we might run tests with this Action on a daily timer, just to make sure new changes will be compatible.
The text was updated successfully, but these errors were encountered: