mirror of
https://github.com/kata-containers/kata-containers.git
synced 2025-08-30 14:25:43 +00:00
Merge pull request #8309 from gkurz/update-release-process-doc
Update release process documentation
This commit is contained in:
Steve Horsman
GitHub
commit
b23952c852
@ -3,22 +3,22 @@
|
||||
|
||||
## Requirements
|
||||
|
||||
- [hub](https://github.com/github/hub)
|
||||
* Using an [application token](https://github.com/settings/tokens) is required for hub (set to a GITHUB_TOKEN environment variable).
|
||||
- [gh](https://cli.github.com)
|
||||
* Install and configure the GitHub CLI (gh) as detailed at https://docs.github.com/en/github-cli/github-cli/quickstart#prerequisites .
|
||||
|
||||
- GitHub permissions to push tags and create releases in Kata repositories.
|
||||
- GitHub permissions to push tags and create releases in the Kata repository.
|
||||
|
||||
- GPG configured to sign git tags. https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key
|
||||
|
||||
- You should configure your GitHub to use your ssh keys (to push to branches). See https://help.github.com/articles/adding-a-new-ssh-key-to-your-github-account/.
|
||||
* As an alternative, configure hub to push and fork with HTTPS, `git config --global hub.protocol https` (Not tested yet) *
|
||||
- `gh auth login` should have configured `git push` and `git pull` to use HTTPS along with your GitHub credentials,
|
||||
* As an alternative, you can still rely on SSH keys to push branches. See https://help.github.com/articles/adding-a-new-ssh-key-to-your-github-account .
|
||||
|
||||
## Release Process
|
||||
|
||||
|
||||
### Bump all Kata repositories
|
||||
### Bump the Kata repository
|
||||
|
||||
Bump the repositories using a script in the Kata packaging repo, where:
|
||||
Bump the repository using the `./update-repository-version.sh` script in the Kata [release](../tools/packaging/release) directory, where:
|
||||
- `BRANCH=<the-branch-you-want-to-bump>`
|
||||
- `NEW_VERSION=<the-new-kata-version>`
|
||||
```
|
||||
@ -28,17 +28,16 @@
|
||||
$ ./update-repository-version.sh -p "$NEW_VERSION" "$BRANCH"
|
||||
```
|
||||
|
||||
### Merge all bump version Pull requests
|
||||
### Merge the bump version Pull request
|
||||
|
||||
- The above step will create a GitHub pull request in the Kata projects. Trigger the CI using `/test` command on each bump Pull request.
|
||||
- Trigger the `test-kata-deploy` workflow which is under the `Actions` tab on the repository GitHub page (make sure to select the correct branch and validate it passes).
|
||||
- The above step will create a GitHub pull request in the Kata repository. Trigger the CI using `/test` command on the bump Pull request.
|
||||
- Check any failures and fix if needed.
|
||||
- Work with the Kata approvers to verify that the CI works and the pull requests are merged.
|
||||
- Work with the Kata approvers to verify that the CI works and the pull request is merged.
|
||||
|
||||
### Tag all Kata repositories
|
||||
### Tag the Kata repository
|
||||
|
||||
Once all the pull requests to bump versions in all Kata repositories are merged,
|
||||
tag all the repositories as shown below.
|
||||
Once the pull request to bump version in the Kata repository is merged,
|
||||
tag the repository as shown below.
|
||||
```
|
||||
$ cd ${GOPATH}/src/github.com/kata-containers/kata-containers/tools/packaging/release
|
||||
$ git checkout <kata-branch-to-release>
|
||||
@ -46,24 +45,6 @@
|
||||
$ ./tag_repos.sh -p -b "$BRANCH" tag
|
||||
```
|
||||
|
||||
### Point tests repository to stable branch
|
||||
|
||||
If your release changes a major or minor version number(not a patch release), then the above
|
||||
`./tag_repos.sh` script will create a new stable branch in all the repositories in addition to tagging them.
|
||||
This happens when you are making the first `rc` release for a new major or minor version in Kata.
|
||||
In this case, you should modify the `tests` repository to point to the newly created stable branch and not the `main` branch.
|
||||
The objective is that changes in the CI on the main branch will not impact the stable branch.
|
||||
|
||||
In the test directory, change references of the `main` branch to the new stable branch in:
|
||||
* `README.md`
|
||||
* `versions.yaml`
|
||||
* `cmd/github-labels/labels.yaml.in`
|
||||
* `cmd/pmemctl/pmemctl.sh`
|
||||
* `.ci/lib.sh`
|
||||
* `.ci/static-checks.sh`
|
||||
|
||||
See the commits in [the corresponding PR for stable-2.1](https://github.com/kata-containers/tests/pull/3504) for an example of the changes.
|
||||
|
||||
### Check Git-hub Actions
|
||||
|
||||
We make use of [GitHub actions](https://github.com/features/actions) in this [file](../.github/workflows/release.yaml) in the `kata-containers/kata-containers` repository to build and upload release artifacts. This action is auto triggered with the above step when a new tag is pushed to the `kata-containers/kata-containers` repository.
|
||||
@ -72,7 +53,7 @@
|
||||
|
||||
### Create release notes
|
||||
|
||||
We have a script in place in the packaging repository to create release notes that include a short-log of the commits across Kata components.
|
||||
We have the `./release-notes.sh` script in the [release](../tools/packaging/release) directory to create release notes that include a short-log of the commits.
|
||||
|
||||
Run the script as shown below:
|
||||
|
||||
@ -82,7 +63,7 @@
|
||||
$ ./release-notes.sh ${OLD_VERSION} ${NEW_VERSION} > notes.md
|
||||
# Edit the `notes.md` file to review and make any changes to the release notes.
|
||||
# Add the release notes in the project's GitHub.
|
||||
$ hub release edit -F notes.md "${NEW_VERSION}"
|
||||
$ gh release edit "${NEW_VERSION}" -F notes.md
|
||||
```
|
||||
|
||||
### Announce the release
|
||||
|
||||
Loading…
Reference in New Issue
Block a user