latest image tags used in the release code

[tumberino]

When using a tagged version of the code the image tag specified for the manager is always latest, but the payload images are tagged to specific digests. Therefore if I try to use version v0.7.0 it doesn't work because of the changes in the way that the runtimeclass gets created in recent updates.

https://github.com/confidential-containers/operator/blob/v0.7.0/config/manager/kustomization.yaml#L13-L16

images:
- name: controller
  newName: quay.io/confidential-containers/operator
  newTag: latest

It would be benefical it the newTag was v0.7.0 in this case. But I understand that that is not a simple fix as the tag gets created as part of the release process.

[stevenhorsman]

Yeah, we have a bit of a cycle here - IIUC the release image of the operator is created by the release process after the tag is done, so if we updated the kustomize to point to this tag before this is cut then I assume that all the tests will fail. I agree that pointing to latest isn't ideal though.

/cc @bpradipt @jensfr @fidencio who might have thoughts/ideas on this

[wainersm]

On peer pods we have a similar issue. There we point to the tag (commit SHA) of the latest built cloud-api-adaptor image before the commit that bump the version. It doesn't point to the version tagged image but at least it will be pinned rather than following latest.

To implement that approach on the operator, we would need to change https://github.com/confidential-containers/operator/blob/main/.github/workflows/docker-publish-latest-on-merge.yml to tag the image with the commit SHA; currently that workflow only publishes to latest.

@fitzthum you might be interested on this issue...