Release Process: Tag CAA image for release with the release version

[surajssd]

Right now we don't tag the CAA's container image with the release tag, we simply update tag with the latest hash:

You should use the commit SHA-1 of the last built quay.io/confidentil-containers/cloud-api-image image to update the overlays kustomization files. For example, suppose the release image is quay.io/confidential-containers/cloud-api-adaptor:6d7d2a3fe8243809b3c3a710792c8498292e2fc3:

Instructions are here: https://github.com/confidential-containers/cloud-api-adaptor/blob/main/docs/Release-Process.md#cutting-releases

[bpradipt]

nit: a typo in the instructions
confidentil-containers -> confidential-containers

[wainersm]

Hi @surajssd !

Right now we don't tag the CAA's container image with the release tag, we simply update tag with the latest hash:

You should use the commit SHA-1 of the last built quay.io/confidentil-containers/cloud-api-image image to update the overlays kustomization files. For example, suppose the release image is quay.io/confidential-containers/cloud-api-adaptor:6d7d2a3fe8243809b3c3a710792c8498292e2fc3:

Suppose the release is 0.9.0.

By the time we cut the release, the quay.io/confidential-containers/cloud-api-adaptor:v0.9.0 does not exist. That image will be built and pushed by the workflow triggered when the release when a release is created.

We will introduce two problems:

• quay.io/confidential-containers/cloud-api-adaptor:v0.9.0 wasn't tested because it didn't exist
• if quay.io/confidential-containers/cloud-api-adaptor:v0.9.0 build fails then we will need to fix and bump the release (0.9.1)

Revisiting again that step, actually we already have a problem:

• quay.io/confidential-containers/cloud-api-adaptor:6d7d2a3fe8243809b3c3a710792c8498292e2fc3 is pinned on the configuration files and it is tested. However the release workflow builds quay.io/confidential-containers/cloud-api-adaptor:v0.9.0 which is not guaranteed to be built from the same sources. One way to solve this is to tag quay.io/confidential-containers/cloud-api-adaptor:6d7d2a3fe8243809b3c3a710792c8498292e2fc3 -> quay.io/confidential-containers/cloud-api-adaptor:v0.9.0 instead of rebuild.

or am I missing something?

Instructions are here: https://github.com/confidential-containers/cloud-api-adaptor/blob/main/docs/Release-Process.md#cutting-releases

[surajssd]

If we can't release something with a tag and then test it, I think something is wrong with the way we do release of CAA or the release of configuration or the process in general and needs fixing. One way I can think of is to disentangle the configuration from the actual code. Or do some sort of -rc releases for testing. And then some -rc becomes the actual release.

[wainersm]

If we can't release something with a tag and then test it, I think something is wrong with the way we do release of CAA or the release of configuration or the process in general and needs fixing. One way I can think of is to disentangle the configuration from the actual code. Or do some sort of -rc releases for testing. And then some -rc becomes the actual release.

Definitively our release process should be reviewed to fix some flaws like that.

We do create -alpha releases but not turn those artifacts into tagged release components.