Integrate krel obs into the release process

[saschagrunert]

First of all we have to publish the release artifacts to the Google Cloud Bucket:

kpromo gh --org kubernetes-sigs --repo cri-tools --bucket k8s-artifacts-cri-tools --release-dir release --tags v1.28.0

Publishes the GitHub artifacts in https://console.cloud.google.com/storage/browser/k8s-artifacts-cri-tools/release

Then we need to run the following commands to release cri-tools in OBS:

krel obs stage --packages cri-tools --version 1.28.0 --project isv:kubernetes:core:stable:v1.28:build --stream --nomock

Runs a Google Cloud Build job and stages:
https://build.opensuse.org/package/show/isv:kubernetes:core:stable:v1.28:build/cri-tools

krel obs release --packages cri-tools --stream --project isv:kubernetes:core:stable:v1.28:build --nomock

Runs a Google Cloud Build job and releases:
https://build.opensuse.org/package/show/isv:kubernetes:core:stable:v1.28/cri-tools.20230814075509

Goal is to integrate the steps above into our release workflow, containing the right amount of permissions:
https://github.com/kubernetes-sigs/cri-tools/blob/master/.github/workflows/release.yml

@kubernetes-sigs/release-engineering we need:

• OBS credentials to run krel obs
• A service account token to access k8s-artifacts-cri-tools

[xmudrii]

I can help with this. I'll add this issue to our project board so that we properly follow it.

[afbjorklund]

Shouldn't this be in kubernetes-release, rather than cri-tools ?

[saschagrunert]

The automation will happen in this repository, we can also consider moving the specfile here.

[saschagrunert]

@kubernetes-sigs/release-engineering how about:

1. Creating a bot account similar to CRI-O to be able to publish packages for cri-tools
2. Move the specfile into this repository
3. Create an publish them similar to https://github.com/cri-o/packaging, but triggered by tags as part of this GitHub action: https://github.com/kubernetes-sigs/cri-tools/blob/master/.github/workflows/release.yml

[xmudrii]

@saschagrunert I think this is a solid plan. I would only try to avoid having a new repo for packaging (because getting repos in k or k-sigs is a more complicated process and it's not scalable).

[saschagrunert]

@xmudrii I'd like to try a full automation here, means we would require a service account being able to push to https://console.cloud.google.com/storage/browser/k8s-artifacts-cri-tools. Can we create on in kubernetes/k8s.io?

[xmudrii]

@saschagrunert Yes, please create an issue in k/k8s.io to track getting a new service account.

[saschagrunert]

@xmudrii closing the loop: kubernetes/k8s.io#5957

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[saschagrunert]

/remove-lifecycle stale

[saschagrunert]

We still need this, and could also think about proposing an automated vendor PR for the RC of a new Kubernetes version. This could include a hint that we may want to cut a release afterwards.