generated from kyma-project/template-repository
-
Notifications
You must be signed in to change notification settings - Fork 23
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Release amendments and GitHub Release changelog improvements (#344)
* Amends the releasing process document. * Adds grouping for the changelog items. * Enhances the grouping for the changelog items with a Bugfix section. * Applies documentation code-review comments.
- Loading branch information
Showing
2 changed files
with
54 additions
and
38 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,41 +1,42 @@ | ||
# Release Process | ||
|
||
1. For new major and minor versions: Create a release branch in the `telemetry-manager` repository. The name of this branch must follow the `release-x.y` pattern, such as `release-1.0`. | ||
|
||
|
||
```bash | ||
This release process covers the steps to release new major and minor versions for the Kyma Telemetry module. | ||
|
||
1. Bump the `telemetry-manager/main` branch with the new versions for the dependent images. | ||
Create a PR to `telemetry-manager/main` with the following changes: | ||
- `Makefile`: | ||
- Ensure the `IMG` variable reflects the latest `telemetry-manager` version. | ||
- Update the `MODULE_VERSION` variable to the value of the new module version. | ||
- `config/manager/kustomization.yaml`: | ||
- Ensure the `newTag` field for the `telemetry-manager` image reflects the latest version. | ||
- `sec-scanners-config.yaml`: | ||
- Ensure that all images listed in the `protecode` field have the same versions as those used in the `main.go` file. | ||
|
||
2. Merge the PR. | ||
|
||
3. In the `telemetry-manager` repository, create a release branch. | ||
The name of this branch must follow the `release-x.y` pattern, such as `release-1.0`. | ||
```bash | ||
git fetch upstream | ||
git checkout --no-track -b {RELEASE_NAME} upstream/main | ||
git push upstream {RELEASE_NAME} | ||
``` | ||
|
||
2. Create a PR to `telemetry-manager/release-x.y` with the following changes: | ||
- `Makefile`: | ||
- Ensure that the `IMG` variable is up to date with the latest `telemetry-manager` version. | ||
- Update the `MODULE_VERSION` variable to the value of the new module version. | ||
- `config/manager/kustomization.yaml`: | ||
- Ensure that the `newTag` field for the `telemetry-manager` image is up to date with the latest version. | ||
- `sec-scanners-config.yaml`: | ||
- Ensure that all of the images listed in the `protecode` field have the same versions as the images used in the `main.go` file. | ||
3. After merging the PR, create a tag on the release branch that has the value of the new module release version. | ||
|
||
```bash | ||
git tag -a {RELEASE_VERSION} -m "Release {RELEASE_VERSION}" | ||
``` | ||
|
||
Replace {RELEASE_VERSION} with the new module release version, for example, `1.0.0`. | ||
|
||
4. To trigger a postsubmit job (`post-telemetry-manager-release-module`) that creates the GitHub release, push the tag. | ||
|
||
```bash | ||
git push upstream {RELEASE_VERSION} | ||
``` | ||
|
||
5. Verify the [Prow Status](https://status.build.kyma-project.io/) of the postsubmit job (`post-telemetry-manager-release-module`). | ||
- Once the postsubmit job succeeds, the new Github release should be available under [releases](https://github.com/kyma-project/telemetry-manager/releases). | ||
- If the postsubmit job failed, you can re-trigger it by removing the tag from upstream and pushing it again: | ||
|
||
```bash | ||
git push --delete upstream {RELEASE_VERSION} | ||
git push upstream {RELEASE_VERSION} | ||
``` | ||
git checkout --no-track -b {RELEASE_BRANCH} upstream/main | ||
git push upstream {RELEASE_BRANCH} | ||
``` | ||
|
||
4. In the `telemetry-manager/{RELEASE_BRANCH}` branch, create a release tag for the head commit. | ||
```bash | ||
git tag -a {RELEASE_VERSION} -m "Release {RELEASE_VERSION}" | ||
``` | ||
Replace {RELEASE_VERSION} with the new module release version, for example, `1.0.0`. The release tag points to the HEAD commit in `telemetry-manager/main` and `telemetry-manager/{RELEASE_BRANCH}` branches. | ||
|
||
5. Push the tag to trigger a postsubmit job (`post-telemetry-manager-release-module`) that creates the GitHub release. | ||
```bash | ||
git push upstream {RELEASE_VERSION} | ||
``` | ||
|
||
6. Verify the [Prow Status](https://status.build.kyma-project.io/) of the postsubmit job (`post-telemetry-manager-release-module`). | ||
- Once the postsubmit job succeeds, the new Github release is available under [releases](https://github.com/kyma-project/telemetry-manager/releases). | ||
- If the postsubmit job failed, retrigger it by removing the tag from upstream and pushing it again: | ||
```bash | ||
git push --delete upstream {RELEASE_VERSION} | ||
git push upstream {RELEASE_VERSION} | ||
``` |