8000 Add tests for local containers in CI · Issue #1413 · sigstore/sigstore-python · GitHub
[go: up one dir, main page]

Skip to content

Add tests for local containers in CI #1413

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 &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.

Already on GitHub? Sign in to your account

Open
ramonpetgrave64 opened this issue May 23, 2025 · 1 comment
Open

Add tests for local containers in CI #1413

ramonpetgrave64 opened this issue May 23, 2025 · 1 comment
Labels
enhancement New feature or request

Comments

@ramonpetgrave64
Copy link
Contributor

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.

@ramonpetgrave64 ramonpetgrave64 added the enhancement New feature or request label May 23, 2025
@jku
Copy link
Member
jku commented May 26, 2025

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:

  1. staging and prod only (status quo)
  2. staging, prod and a local test setup running latest infra releases
  3. 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants
0