Our KBS logic currently checks out the git.kbs version of code, but then edits
the deployment config to override the image based on the oci.kbs version.

This means that there is an assumption that the oci image
of the KBS is compatible with the kustomization, which might not
not always be the case and in the "always safe" case where the
image is built from that exact version of code (e.g. releases), just
means that we have to specify it in two places, so there isn't much advantage
to this approach.

This PR removes the oci.kbs image and versioning to avoid this
potential incompatibility and simplify trustee version updates.

Fixes: confidential-containers#2076
Signed-off-by: stevenhorsman <[email protected]>

Our KBS logic currently checks out the git.kbs version of code, but then edits
the deployment config to override the image based on the oci.kbs version.

This means that there is an assumption that the oci image
of the KBS is compatible with the kustomization, which might not
not always be the case and in the "always safe" case where the
image is built from that exact version of code (e.g. releases), just
means that we have to specify it in two places, so there isn't much advantage
to this approach.

This PR removes the oci.kbs image and versioning to avoid this
potential incompatibility and simplify trustee version updates.

Fixes: confidential-containers#2076
Signed-off-by: stevenhorsman <[email protected]>

Our KBS logic currently checks out the git.kbs version of code, but then edits
the deployment config to override the image based on the oci.kbs version.

This means that there is an assumption that the oci image
of the KBS is compatible with the kustomization, which might not
not always be the case and in the "always safe" case where the
image is built from that exact version of code (e.g. releases), just
means that we have to specify it in two places, so there isn't much advantage
to this approach.

This PR removes the oci.kbs image and versioning to avoid this
potential incompatibility and simplify trustee version updates.

Because there is a chance that the trustee team might not keep
their kustomizational image up-to-date, the recommendation is
that we should ensure that the image version matches the branch
we are using, so perform a kustomize set image at the time we clone
the repo.

Fixes: confidential-containers#2076
Signed-off-by: stevenhorsman <[email protected]>

Our KBS logic currently checks out the git.kbs version of code, but then edits
the deployment config to override the image based on the oci.kbs version.

This means that there is an assumption that the oci image
of the KBS is compatible with the kustomization, which might not
not always be the case and in the "always safe" case where the
image is built from that exact version of code (e.g. releases), just
means that we have to specify it in two places, so there isn't much advantage
to this approach.

This PR removes the oci.kbs image and versioning to avoid this
potential incompatibility and simplify trustee version updates.

Because there is a chance that the trustee team might not keep
their kustomizational image up-to-date, the recommendation is
that we should ensure that the image version matches the branch
we are using, so perform a kustomize set image at the time we clone
the repo.

As trustee have a separate container registry for development
versus release images for reasons, they only automatically push
builds to the staged-images registry, which are tagged by the sha
of the commit, so we need to convert the KBS_VERSION given
into the sha and then replace the image with the staged-images kbs

Fixes: confidential-containers#2076
Signed-off-by: stevenhorsman <[email protected]>

Our KBS logic currently checks out the git.kbs version of code, but then edits
the deployment config to override the image based on the oci.kbs version.

This means that there is an assumption that the oci image
of the KBS is compatible with the kustomization, which might not
not always be the case and in the "always safe" case where the
image is built from that exact version of code (e.g. releases), just
means that we have to specify it in two places, so there isn't much advantage
to this approach.

This PR removes the oci.kbs image and versioning to avoid this
potential incompatibility and simplify trustee version updates.

Because there is a chance that the trustee team might not keep
their kustomizational image up-to-date, the recommendation is
that we should ensure that the image version matches the branch
we are using, so perform a kustomize set image at the time we clone
the repo.

As trustee have a separate container registry for development
versus release images for reasons, they only automatically push
builds to the staged-images registry, which are tagged by the sha
of the commit, so we need to convert the KBS_VERSION given
into the sha and then replace the image with the staged-images kbs

Fixes: confidential-containers#2076
Signed-off-by: stevenhorsman <[email protected]>