-
Notifications
You must be signed in to change notification settings - Fork 10
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
Create mock Fulcio and Rekor instances #25
Comments
I think we can test against production/staging for now. |
I've been thinking about this more and doing a bit of testing. I think our mock instances (at least for Rekor) actually have to be quite smart for this to work. In order to return a working inclusion proof, I think we need to maintain an actual Merkle tree in the mock. Unless we decide to do something like pretend the tree is always just the root + the node you're verifying and ignore everything else that the client uploaded. I'm going to try that first and see if we can get away with that since I'd rather not have a super complex mock. |
Just want to reiterate that I think we can test against production/staging for now. |
I see no harm against testing against staging. Any reason you’d need to test against production? |
I don't think we have an immediate reason to test against production since things have stabilized a bit, but one potential future reason is to avoid superfluous test failures when we know staging is diverging. (My understanding, which might be wrong, is that the point of the conformance suite is to make sure that the various Sigstore clients share common user-facing behavior and don't accidentally regress on that behavior, so it makes sense for the suite to track both the staging and production instances.) |
Sure. I'm trying to fill out the test cases now though, which will require mocks. Although @asraa made a good point in #30 that I can rely on canned responses from a real Rekor instance (maybe that I've tampered with by hand), and then have a simple mock that just replays them. |
This was something that I saw mentioned in the design. The idea is to have the test suite automatically spin up mock instances for testing purposes.
@di, is this something that you'd still like to have, as opposed to testing against the production or staging instances?
The text was updated successfully, but these errors were encountered: