Release automation

[antoooks]

Eschewed features

• [x] This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

Automated release process of Kustomize and its components

Why is this needed?

Releasing kustomize and it's component currently requires 2-3 hours of attended session with a lot of manual steps in between, making the release process slow and inefficient. On top of that, release officer also need to do some extra steps post-release such as unpinning the library versions, returning the branch to dev mode, making PRs, pushing docker image, etc.

Moreover, after the new release scheme, which will synchronise all component's version, the process of determining release size must be reviewed.

By introducing automation we can remove a lot of manual tasks and makes the release experience much smoother and more efficient.

Can you accomplish the motivating task without this feature, and if so, how?

Yes, release can still manually be done by following steps on releasing/README.md

What other solutions have you considered?

Release automation flow will be described as follows:

1. Release officer will call a release script supplying the component name and release size. Release size not determined automatically due to the consideration that sometimes it needs human judgement to justify the release size.

For example ./release kyaml major

2. Release script will (a) create a new branch in the format of release-{component}/vX.Y.Z , (b) pin the component version according to the release size supplied, (c) create release draft of that component

3. Ideally it should notify the maintainers that release has been succeeded / failed. However due to limitation of the implementation we must rely on Github notification or manually check the workflow status

4. Once release has been completed, release officer will check the release draft and publish them once it's ready.

Automation will be done via Github Workflow

Anything else we should know?

None

Feature ownership

• [x] I am interested in contributing this feature myself! 🎉

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[antoooks]

Please let me know your feedback on the plan /assign @koba1t

[koba1t]

Thanks, @antoooks !

I believe it is almost good!

Can I ask for one favor? I would like to be able to go from kyaml to kustomize release in one script to run a single command to release a new kustomize binary, rather than running multiple commands in sequence.

For example ./release minor

- minor new release of `kyaml` (kyaml/v0.19.0 -> kyaml/v0.20.0)
- minor new release of `cmd/config` (cmd/config/v0.19.0 -> cmd/config/v0.20.0)
- minor new release of `api` that import the above `kyaml` version (api/v0.19.0 -> api/v0.20.0)
- minor new release of `kustomize` that import above `kyaml` and `api` version (kustomize/v5.6.0 -> kustomize/v5.7.0)

I think this would be simple and less work to create a release.

[antoooks]

Noted @koba1t thank you for the feedback

[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

[koba1t]

/remove-lifecycle stale

[devikrishnamk0123]

Hi @antoooks @koba1t 👋

I’d love to contribute to this issue. I'm a DevOps engineer with experience in GitHub Actions, shell scripting, and release automation. I’ve reviewed the current release documentation and would be happy to help automate the multi-module release process, starting with a script or workflow that runs through the kyaml → cmd/config → api → kustomize sequence.

I'm not a Kubernetes org member yet, but would love to collaborate and contribute. Let me know how I can begin or if you'd like me to propose an initial PR.

Thanks!

[antoooks]

Hi @antoooks @koba1t 👋

I’d love to contribute to this issue. I'm a DevOps engineer with experience in GitHub Actions, shell scripting, and release automation. I’ve reviewed the current release documentation and would be happy to help automate the multi-module release process, starting with a script or workflow that runs through the kyaml → cmd/config → api → kustomize sequence.

I'm not a Kubernetes org member yet, but would love to collaborate and contribute. Let me know how I can begin or if you'd like me to propose an initial PR.

Thanks!

Hi @devikrishnamk0123 ! Thanks for your interest to work on this issue. Please refer to this section for current release process.

Currently we're using a unified version for all sub-modules of kustomize (kyaml, cmd/config, api) while maintaining the versioning of kustomize. For example, the next minor release will result in this versioning

kyaml -> from 0.20.1 to 0.21.1 cmd/config -> from 0.20.1 to 0.21.1 api -> from 0.20.1 to 0.21.1

Does not matter where the change occurs, all submodules must be version bumped. As for Kustomize it will retain it's versioning.

kustomize -> from 5.7.1 to 5.8.1

In case of major bump on kustomize, it will be discussed within the SIG due to its breaking nature.

The automation must cover use cases as follows:

• At the moment the process of pinning, releasing, and unpinning libraries are done manually and PR are made manually to review changes during pinning process. A lot of manual command execution need to be done and undone due to the release processes happening at the master branch. We would like an automation that creates a release branch of each submodules and do pinning and releasing on that branch, and, create a release draft, and finally create a PR automatically, we will maintain the approval process which is still a manual process.
• The order of releasing must be: kyaml, cmd/config, api, and finally kustomize binary
• Version bumping is done at the start of the automation and the release size (patch, minor, major) is determined manually and best if treated as an input to the automation
• It's highly suggested to use combination of script and Github pipeline, but if you have another suggestion on how to approach the release automation we are open to hear it

That's all I can elaborate, if you need any clarification please let us know.

Regards,

[koba1t]

/assign @tsuzu

[tsuzu]

Hi @koba1t According to #5800, we'll use the same version for all sub packages, but do we plan to have releases of different sizes for kustomize and internal pkgs? For example, a new major release for kustomize, but a new minor release for internal pkgs.

[koba1t]

Hi @tsuzu #5800 also mentions this, but we want to keep the release process simple by decide new release versions based on the minimum impact size across all affected pkgs. In fact, because the sigs.k8s.io/kustomize/kustomize implementation is thin, the amount of changes to internal packages will be nearly identical to the changes in the kustomize binary release.

Therefore, I would use to same size release of both(internal pkgs and kustomize binary) releases.