Installation image is using wrong tag by default

[mxmxchere]

What happened:
The installation container cannot be started due to wrong default image tag

Normal  BackOff  4m20s (x661 over 153m)  kubelet  Back-off pulling image "eu.gcr.io/gardener-project/gardener/extensions/runtime-gvisor-installation:v0.5.1-dev"

What you expected to happen:
A proper image tag to be used by default.

How to reproduce it (as minimally and precisely as possible):

Create a shoot cluster with worker pool with gVisor enabled. With the following controller-registration.yaml: https://raw.githubusercontent.com/gardener/gardener-extension-runtime-gvisor/v0.5.1/example/controller-registration.yaml

Anything else we need to know?:
The issue lies (as far as we found out) in the gvisor-runtime image https://console.cloud.google.com/gcr/images/gardener-project/eu/gardener%2Fextensions%2Fruntime-gvisor@sha256:866ea708c0ce5e5c64b9dc1a290b89caa90151691253d328af4155cdf4e64f3f which creates a daemonset with a "-dev" image tag. We had a look at the included binary and found the string "v0.5.1-dev". If we build the image locally (with v0.5.1 checked out) this string is "v0.5.1". So we assume that a wrong version is linked into the upstream image. Currently we assume an issue in the build pipeline but unfortunately we cant get the log from the respective run: https://concourse.ci.gardener.cloud/teams/gardener/pipelines/gardener-extension-runtime-gvisor-release-v0.5/jobs/release-v0.5-release-job/builds/1

Environment:

• Gardener version : 1.46
• Extension version: 0.5.1
• Kubernetes version (use kubectl version): 1.23
• Cloud provider or hardware configuration:
• Others:

[Diaphteiros]

I just ran into this issue too. This doesn't happen in our landscapes usually, because we are using an imageVectorOverwrite there, which overwrites the image in question and thus mitigates the problem.

The image tag for the daemonset on the shoot is set here: https://github.com/gardener/gardener-extension-runtime-gvisor/blob/v0.6.0/pkg/charts/values.go#L48. I assume that this returns the wrong version (with a -dev suffix), but I wasn't able to verify this yet, as calling the function locally just returns no version at all.

This basically makes the runtime-gvisor extension unusable without an imageVectorOverwrite.

[ialidzhikov]

We just hit this issue with @dimitar-kostadinov. I think this is introduced by #38 (cc @andrerun @vpnachev).

$ docker run eu.gcr.io/gardener-project/gardener/extensions/runtime-gvisor:v0.7.0-dev-9b562acbdb1ee8dd1abb49f65c0ce85fbe85766d --version=raw
version.Info{Major:"0", Minor:"7+", GitVersion:"v0.7.0-dev", GitCommit:"9b562acbdb1ee8dd1abb49f65c0ce85fbe85766d", GitTreeState:"clean", BuildDate:"2022-09-06T10:15:09+00:00", GoVersion:"go1.18.5", Compiler:"gc", Platform:"linux/amd64"}

# the GitVersion should be v0.7.0-dev-9b562acbdb1ee8dd1abb49f65c0ce85fbe85766d while it is v0.7.0-dev

$ docker run eu.gcr.io/gardener-project/gardener/extensions/runtime-gvisor:v0.6.0 --version=raw
version.Info{Major:"0", Minor:"6+", GitVersion:"v0.6.0-dev", GitCommit:"0ecf3a272aebaafd845f8b6a6310c41bc2cc94ed", GitTreeState:"clean", BuildDate:"2022-09-02T13:18:26+00:00", GoVersion:"go1.18.5", Compiler:"gc", Platform:"linux/amd64"

# the GitVersion should be v0.6.0 while it is v0.6.0-dev

[vpnachev]

On a first look, this looks like an issue with the propagation of the effective version during the builds in CI/CD.

[vpnachev]

Indeed seems to be so. According to docs inject_effective_version is disabled by default and it is not explicitly enabled neither in the .ci/pipeline_definitions, nor in the branch.cfg.