Automate release process

[fmuyassarov]

By quickly looking at #870, I understand that most of the release steps are performed manually. What do you think about automating the steps that are possible to automate?
I assume, at least the following steps can be automated

• For major releases (v0.$MAJ.0) create new release branch
• Run scripts/prepare-release.sh $VERSION to turn references to point to the upcoming release
• Submit a PR against k8s.io, updating k8s.gcr.io/images/k8s-staging-nfd/images.yaml to promote the container images (both "full" and "minimal" variants) to production
• Send an announcement email to [email protected] with the subject [ANNOUNCE] node-feature-discovery $VERSION is released

One easy way to automate could be using GitHub Actions or we can check if we have some other alternatives too.

[marquiz]

Sure, at least I like automation 😊 I think contributions on that front are more than welcome

Some quick thoughts:

For major releases (v0.$MAJ.0) create new release branch

I think this would be relatively straightforward, probably use a manual dispatch to trigger(?)

Run scripts/prepare-release.sh $VERSION to turn references to point to the upcoming release

Should work fine, could be tied to the release branch creation(?) What still needs to be done manually is to create the artifacts (Helm chart and its signature file) and upload them to a release draft.

Submit a PR against k8s.io, updating k8s.gcr.io/images/k8s-staging-nfd/images.yaml to promote the container images (both "full" and "minimal" variants) to production

This could be even fully automated (on triggered on release tags), although it takes a considerable time (15 to 20 min) for the k8s test-infra to build and push all images. We have a make target (make poll-images) for checking if images have been published. The shell code from there could be extracted into a separate script.

Send an announcement email to [email protected] with the subject [ANNOUNCE] node-feature-discovery $VERSION is released

I'm not sure about this. Of course there could be manually triggerable automation if you don't want to put any personalization in the email 😄

[fmuyassarov]

For major releases (v0.$MAJ.0) create new release branch

I think this would be relatively straightforward, probably use a manual dispatch to trigger(?)

or GitHub Action, but not sure how we would manage the tokens...Maybe k8s robot can help but I need to check to be honest.

Run scripts/prepare-release.sh $VERSION to turn references to point to the upcoming release

Should work fine, could be tied to the release branch creation(?) What still needs to be done manually is to create the artifacts (Helm chart and its signature file) and upload them to a release draft.

Yes, I think we could tied up many things to the tag creation. For example, if an owner pushes a tag that increments the MINOR or MAJOR version, then create a branch and related artifacts generations, otherwise only artifacts generation but not branching out. But I imagine that this would be done by GitHub bot account (probably k8s-github-robot could help here...) who has enough rights on the GitHub repo.

Submit a PR against k8s.io, updating k8s.gcr.io/images/k8s-staging-nfd/images.yaml to promote the container images (both "full" and "minimal" variants) to production

This could be even fully automated (on triggered on release tags), although it takes a considerable time (15 to 20 min) for the k8s test-infra to build and push all images. We have a make target (make poll-images) for checking if images have been published. The shell code from there could be extracted into a separate script.

Yep, I was thinking about k8s test-infra too, but running local script also sounds fine to me.

Send an announcement email to [email protected] with the subject [ANNOUNCE] node-feature-discovery $VERSION is released

I'm not sure about this. Of course there could be manually triggerable automation if you don't want to put any personalization in the email smile

Yes, if you we want to customize the email in the future, then it requires submitting a patch, review, merge... too much 😃

But if you think we could benefit from it, I can spend some time to investigate what&how to automate, then come with one or more options and eventually submit a patch once everyone agrees.