-
Notifications
You must be signed in to change notification settings - Fork 58
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
Make the release artifacts more granular. #252
Comments
I started to do this here: And ideally we'd break this to create multiple artifacts similarly, maybe a for loop here: And lastly also need to release ./hack/setup-scaffolding.sh like we do ./hack/setup-kind.sh These are notes mainly for myself, but if @cpanato you find some time (not a big deal if you can't) to make sure this looks right I'd appreciate it. |
Little more background on the necessity for doing this. Since switching to using TUF root vs. env variables, we need to do a manual step for copying the various secrets that TUF root needs (ctlog, fulcio, and rekor) to TUF namespace so that it can construct a root from them. We could probably do by creating a bundle with ctlog, trillian, fulcio, and rekor into a single bundle, but coupled with the speed ups that come from doing things in a sequence this makes sense to do it one by one. |
you find the time before me :) |
LOL, for once :) |
Description
While it's convenient to do a one fell swoop and launch all the jobs at the same time, it does make things slower because of the exponential back-off that jobs use. Since there are several jobs that get launched simultaneously and because previous jobs need to finish before the final ones do, by the time we get to later stage jobs, they are backing off into the minutes.
So, if we create the release artifacts along the lines of steps as in the README.md and then launch those and wait for them to finish before starting the next step, we could shave off (guesstimate, minutes?) off the startup time.
I think the natural break from README (trillian, rekor, ctlog, fulcio) might make sense and make things more granular. But I think even just pulling the trillian into it's own would be good.
There's this PR that might help with that:
google/trillian#2754
So, if we get that merged in, then we can remove some bits from here. But, this is just keeping track of this thought, as well as depending on how long it takes me to get that in, might start some work here ahead 🤷
The text was updated successfully, but these errors were encountered: