doc: No longer release the test repository

Now that most of the test repository got migrated to the main Kata repository,
it is no longer needed to tag the test repository when doing a release.

Update the documentation accordingly by dropping all references to the test
repository and only mention *the* Kata repository.

Fixes #8302

Signed-off-by: Greg Kurz <groug@kaod.org>
This commit is contained in:
Greg Kurz 2023-10-24 15:49:12 +02:00
parent af2d897fb1
commit b27b4ce104

View File

@ -6,7 +6,7 @@
- [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
@ -16,9 +16,9 @@
## 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,16 +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.
- 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>
@ -45,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.
@ -71,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: