workflow: pin docker image version to release version

[ChengyuZhu6]

pin docker image version to release version.

[wainersm]

Hi @ChengyuZhu6 !

Thanks for working on this; on Kata CI we use these deployments to install nydus-snapshotter and we realized while ago that the version wasn't pinned, thus this is very important to us.

One problem that I see with this fix is that the misc/snapshotter/base/nydus-snapshotter.yaml gets changed after the repository tagging. The way that Kata CI consume these files is by cloning the repo and checking the release tag, and in this case misc/snapshotter/base/nydus-snapshotter.yaml will be still pointing to latest image. This a chicken-or-eggs situation that I've seen in peer pods and other projects :(

One way of solve that problem is to consume this project tarball sources file. There the misc/snapshotter/base/nydus-snapshotter.yaml will be pointing to the right and pinned image. On the other hand, by leveraging this approach we lose the ability to consume this project from a given commit SHA-1.

There is another approach that I will say later because I will be better expressing the idea in code :)

[wainersm]

The other idea I mentioned above is to create a new release overlay that overwrites the image tag on the base deployment. Something like that:

$ tree
.
├── base
│   ├── kustomization.yaml
│   └── nydus-snapshotter.yaml
├── config-blockdev.toml
├── config-proxy.toml
├── config.toml
├── Dockerfile
├── nydusd-config.fscache.json
├── nydusd-config.fusedev.json
├── nydusd-config-localfs.json
├── nydus-snapshotter.fscache.service
├── nydus-snapshotter.fusedev.service
├── nydus-snapshotter-rbac.yaml
├── nydus-snapshotter.service
├── overlays
│   ├── k3s
│   │   ├── kustomization.yaml
│   │   └── mount_k3s_conf.yaml
│   ├── release
│   │   └── kustomization.yaml
│   └── rke2
│       ├── kustomization.yaml
│       └── mount_rke2_conf.yaml
└── snapshotter.sh

6 directories, 19 files

$ cat overlays/release/kustomization.yaml 
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base

# newTag points to the latest release image and must be updated before tagging a new release
images:
- name: ghcr.io/containerd/nydus-snapshotter
  newTag: v0.13.9
$ kustomize build base/ | grep ghcr.io/containerd/nydus-snapshotter
        image: ghcr.io/containerd/nydus-snapshotter:latest
$ kustomize build overlays/release/ | grep ghcr.io/containerd/nydus-snapshotter
        image: ghcr.io/containerd/nydus-snapshotter:v0.13.9

The overlays/release/kustomization.yaml file should be updated to the release tag before tagging the repo and creating the release. Users will install the release snapshotter with kubectl apply -k overlays/release then.

This isn't a novel idea nor mine. It's being used on the CoCo operator too, see https://github.com/confidential-containers/operator/tree/main/config/release and https://github.com/confidential-containers/operator/blob/main/docs/INSTALL.md#deploy-the-operator