kingdonb
commented
1 year ago I'm comfortable leaving the "assessment" parts of this incomplete until we have a few more eyes on this.
There are signatures, and OCI artifacts are deployed as "production" and "dev" environments, here:
We're not using any containers for the GitHub Actions "prod-lite", and there's nothing tracking that, I'm not sure it's needed.
We might eventually adopt containers for "prod-lite 2.0" when it's implemented on top of KEDA, but right now it's actually cheaper for us to spin up a GHA with kind cluster every time we need to take a measurement, as GitHub is paying for it (vs. a dev cluster which either needs to consume a bit of electricity in my own homelab or in the cloud, both costing some money).
Converting #35 and #36 to issues which can live their own lives after this one closes.
The new release workflow should make use as much as possible of our existing development builds from the main branch, in terms of reusing existing steps, and cache if possible.
We can borrow parts of the release workflow from
podinfoand we can look to Flux itself for more examples of how the ideal production release workflow should look, on the leading edge of today's security trends. 🦖🔥👩🍳💋🤌We should publish a Flux OCI release artifact for each tag, and it should match roughly the filesystem structure of podinfo, where there are different overlays, and it can support different environments with each release. We can adopt the OCI artifact for use in Dev, Test, and Prod, and make that the Flux delivery infrastructure for this project in each environment where it's currently hosted.