106 lines
5.1 KiB
Markdown
106 lines
5.1 KiB
Markdown
# Kaniko Release Process
|
|
|
|
This document explains the Kaniko release process.
|
|
|
|
Kaniko is not an officially supported Google product. Kaniko is maintained by Google.
|
|
|
|
|
|
## Self-Serve Kaniko Release [Non-Google contributors]
|
|
Kaniko is not an officially supported Google product however only contributors part of
|
|
Google organization can release Kaniko to official kaniko project at `kaniko-project`.
|
|
If you are a part of [Google organization](https://github.com/orgs/google/people), please see skip to [Kaniko Release Process - Google Contributors](https://github.com/GoogleContainerTools/kaniko/blob/master/RELEASE.md#kaniko-release-process-google-contributors)
|
|
|
|
Non-Google Contributors or users, please follow the following steps:
|
|
1. Follow the setup instruction to fork kaniko repository [here](https://github.com/GoogleContainerTools/kaniko/blob/master/DEVELOPMENT.md#getting-started)
|
|
2. Run the following `make` commands to build and push Kaniko image to your organization image repository.
|
|
```shell
|
|
REGISTRY=gcr.io/YOUR-PROJECT make images
|
|
```
|
|
The above command will build and push all the 3 kaniko images
|
|
* gcr.io/YOUR-PROJECT/executor:latest
|
|
* gcr.io/YOUR-PROJECT/executor:debug
|
|
* gcr.io/YOUR-PROJECT/warmer:latest
|
|
|
|
3. You can choose tag these images using `docker tag`
|
|
e.g. To tag `gcr.io/YOUR-PROJECT/executor:latest` as `gcr.io/YOUR-PROJECT/executor:v1.6.0self-serve`, run
|
|
```shell
|
|
docker tag gcr.io/YOUR-PROJECT/executor:latest gcr.io/YOUR-PROJECT/executor:v1.6.0self-serve
|
|
```
|
|
|
|
Please change all usages of `gcr.io/kaniko-project/executor:latest` to `gcr.io/YOUR-PROJECT/executor:latest` for executor image and so on.
|
|
4. Finally, pushed your tagged images via docker. You could also use the Makefile target `push` to push these images like this
|
|
```shell
|
|
REGISTRY=gcr.io/YOUR-PROJECT make images
|
|
```
|
|
|
|
## Kaniko Release Process [Google Contributors]
|
|
### Getting write access to the Kaniko Project
|
|
In order to kick off kaniko release, you need to write access to Kaniko project.
|
|
|
|
To get write access, please ping one of the [Kaniko Mantainers](https://github.com/orgs/GoogleContainerTools/teams/kaniko-maintainers/members).
|
|
|
|
Once you have the correct access, you can kick off a release.
|
|
|
|
|
|
### Kicking of a release.
|
|
|
|
1. Create a release PR and update Changelog.
|
|
|
|
In order to release a new version of Kaniko, you will need to first
|
|
|
|
a. Create a new branch and bump the kaniko version in [Makefile](https://github.com/GoogleContainerTools/kaniko/blob/master/Makefile#L16)
|
|
|
|
|
|
In most cases, you will need to bump the `VERSION_MINOR` number.
|
|
In case you are doing a patch release for a hot fix, bump the `VERSION_BUILD` number.
|
|
|
|
b. Run the [script](https://github.com/GoogleContainerTools/kaniko/blob/master/hack/release.sh) to create release notes.
|
|
```
|
|
./hack/release.sh
|
|
Collecting pull request that were merged since the last release: v1.0.0 (2020-08-18 02:53:46 +0000 UTC)
|
|
* change repo string to just string [#1417](https://github.com/GoogleContainerTools/kaniko/pull/1417)
|
|
* Improve --use-new-run help text, update README with missing flags [#1405](https://github.com/GoogleContainerTools/kaniko/pull/1405)
|
|
...
|
|
Huge thank you for this release towards our contributors:
|
|
- Alex Szakaly
|
|
- Alexander Sharov
|
|
```
|
|
Copy the release notes and update the [CHANGELOG.md](https://github.com/GoogleContainerTools/kaniko/blob/master/CHANGELOG.md) at the root of the repository.
|
|
|
|
c. Create a pull request like [this](https://github.com/GoogleContainerTools/kaniko/pull/1388) and get it approved from Kaniko maintainers.
|
|
|
|
2. Once the PR is approved and merged, create a release tag with name `vX.Y.Z` where
|
|
```
|
|
X corresponds to VERSION_MAJOR
|
|
Y corresponds to VERSION_MINOR
|
|
Z corresponds to VERSION_BUILD
|
|
```
|
|
E.g. to release 1.2.0 version of kaniko, please create a tag v1.2.0 like this
|
|
```
|
|
git pull remote master
|
|
git tag v1.2.0
|
|
git push remote v1.2.0
|
|
```
|
|
3. Pushing a tag to remote with above naming convention will trigger the Github workflow action defined [here](https://github.com/GoogleContainerTools/kaniko/blob/main/.github/workflows/images.yaml) It takes 20-30 mins for the job to finish and push images to [`kaniko-project`](https://pantheon.corp.google.com/gcr/images/kaniko-project?orgonly=true&project=kaniko-project&supportedpurview=organizationId)
|
|
```
|
|
gcr.io/kaniko-project/executor:latest
|
|
gcr.io/kaniko-project/executor:vX.Y.Z
|
|
gcr.io/kaniko-project/executor:debug
|
|
gcr.io/kaniko-project/executor:debug-vX.Y.Z
|
|
gcr.io/kaniko-project/executor:warmer
|
|
gcr.io/kaniko-project/executor:warmer-vX.Y.Z
|
|
```
|
|
You could verify if the images are published using the `docker pull` command
|
|
```
|
|
docker pull gcr.io/kaniko-project/executor:warmer-vX.Y.Z
|
|
```
|
|
In case the images are still not published, ping one of the kaniko manintainers and they will provide the cloud build trigger logs.
|
|
You can also request read access to the Google `kaniko-project`.
|
|
|
|
4. Finally, once the images are published, create a release for the newly created [tag](https://github.com/GoogleContainerTools/kaniko/tags) and publish it.
|
|
Summarize the change log to mention,
|
|
- new features added if any
|
|
- bug fixes,
|
|
- refactors and
|
|
- documentation changes
|