Helm chart artifact promotion and releasing

[fmuyassarov]

I was trying to figure out what needs to be done to setup things around Helm chart promotion as an OCI artifact and I was hoping that it would be very similar to the images of the driver as both charts and container images are OCI artifacts.
Here is what I think we can do during the release process and I would appreciate your thoughts on this:

1. Someone with write access on dranet repo pushes a release tag

   git tag -a v1.1.1 -m "Release v1.1.1"
   git push origin v1.1.1

   The Prow postsubmit job post-dranet-image in k8s-staging-dranet.yaml kicks off and triggers the cloud build run based on our cloudbuild.yaml.

2. cloudbuild.yaml runs two steps:

   make release - which builds and pushes the image to staging repo - gcr.io/k8s-staging-networking/dranet:<_GIT_TAG>
make helm-push (TODO) - which packages and pushes the chart as an OCI artifact to the same staging repo - gcr.io/k8s-staging-networking/charts/dranet:<_GIT_TAG> (TODO)

3. We obtain artifact digests

   Once the cloud build run succeeds, we will retrieve the SHA for both artifacts from the build output or we just run

   crane digest gcr.io/k8s-staging-networking/dranet:<_GIT_TAG>
   crane digest gcr.io/k8s-staging-networking/charts/dranet:<_GIT_TAG>

4. We then promote artifacts from staging to production registry

   So here, we open up a PR to k8s.io dranet/images.yaml. So, on top of already existing dranet entry we will have charts/dranet entry

   - name: dranet
     dmap:
       "sha256:<IMAGE_DIGEST>": ["v1.1.1"]
   ...
   
   - name: charts/dranet
     dmap:
       "sha256:<CHART_DIGEST>": ["v1.1.1"]

   Once the PR is merged, the post-k8sio-image-promo postsubmit job in k8s.io/test-infra will promote both artifacts.

5. Finally, we double check that artifacts are promoted

   crane digest registry.k8s.io/networking/dranet:v1.1.1
   helm show chart oci://registry.k8s.io/networking/charts/dranet --version 1.1.1
   # or
   helm install dranet oci://registry.k8s.io/networking/charts/dranet --version 1.1.1

Does this sound correct to you?

Is that okay that we keep helm chart artifact under the same dranet/images.yaml so that we avoid creating a separate staging repo and google groups, etc?

[fmuyassarov]

and I think we should document the whole releasing process before we forget :)

[fmuyassarov]

@gauravkghildiyal do you have any opinions on this as I can see you have been involved in cutting the latest releases?

[gauravkghildiyal]

I'm not an expert with helm charts, but looking around and what you've described makes sense to me. Thanks for helping out!

We definitely need to add these required details to the release process documentation. At the moment, even the non-helm-chart DRANET images promotion isn't documented.

[fmuyassarov]

I'm not an expert with helm charts, but looking around and what you've described makes sense to me.

No problem, nor am I'm an expert 😁

I think if we treat them as another OCI artifact, we can just follow the same steps similar to container images. I have a rough idea of what’s required to get a very basic setup working for chart promotion, but I wanted to double-check with you all before I start filing the necessary patches.
Also, @aojea @michaelasp if you folks have anything to add/against this - would be happy to hear.

[michaelasp]

Same, not much of an expert on helm chart releasing. I've mostly used them internally with build tooling. Definitely would love some documentation but I have nothing against this promotion process. Thanks for all your help adding this to the project!

[aojea]

@ameukam for help to evaluate the process, from my perspective it looks correct

[fmuyassarov]

Thanks for the opinions everyone.

For the sake of tracking, I will keep the list of the patches here that will be needed - before we can conclude the whole process as done (there are not that many)

• somewhat related: docs: describe the release process #131
• chart publishing changes on the dranet chore: add helm chart packaging & pushing to release process #130
• registry related changes in k8s.io (TODO: After the next release, once we have the SHA for the chart, this should not require any additional work from us apart from promoting the staging chart. The cloudbuild.yaml changes in #130 will take care of pushing it to staging)