github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

More improves for K3s patch release docs (#8800) 

* add more improves for patch releases

Signed-off-by: Johnatas <johnatas.santos@suse.com>

* a simple detail

Signed-off-by: Johnatas <johnatas.santos@suse.com>

---------

Signed-off-by: Johnatas <johnatas.santos@suse.com>
pull/8894/head
Johnatas 2023-11-16 14:35:45 -03:00 committed by GitHub
parent abc2efdd57
commit da0593bcf9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 22 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/release/expanded/cut_release.md
View File

@ -3,6 +3,7 @@
1. Verify that the merge CI has successfully completed before cutting the RC
1. After the merge CI has completed, cut an RC by creating a release in the GitHub interface
1. the title is the version of k3s you are releasing with the rc1 subversion eg. "v1.25.0-rc1+k3s1"
1. In the case of a update to k3s, it should be incremented from `k3s1` to `k3s2`, for example, meaning the k3s version is being incremented.
1. the target should match the release branch, remember that the latest version is attached to "master"
1. no description
1. the tag should match the title

17
docs/release/expanded/release_images.md
View File

@ -1,15 +1,17 @@
# Create Release Images
## Create System Agent Installer Images
## Check System Agent Installer Images
The k3s-io/k3s Release CI should dispatch the rancher/system-agent-installer-k3s repo, generating a tag there and triggering the CI to build images.
The system-agent-installer-k3s repository is used with Rancher v2prov system.
This often fails! Check the CI and if it was not triggered do the following:
After RCs are cut you need to manually release the system agent installer k3s, this along with KDM PR allows QA to fully test RCs.
After RCs are cut you need to check the system agent installer k3s, this along with KDM PR allows QA to fully test RCs.
This should happen directly after the KDM PR is generated, within a few hours of the release candidate being cut.
These images depend on the release artifact and can not be generated until after the k3s-io/k3s release CI completes.
Build progress can be tracked [here](https://hub.docker.com/r/rancher/system-agent-installer-k3s/tags).
This often fails! Check the CI and if it was not triggered do the following:
1. Create a release in the system-agent-installer-k3s repo
1. it should exactly match the release title in the k3s repo
1. the target is "main" for all releases (no branches)
@ -18,12 +20,17 @@ These images depend on the release artifact and can not be generated until after
1. Watch the Drone Publish CI, it should be very quick
1. Verify that the new images appear in Docker hub
## Create K3S Upgrade Images
## Check K3S Upgrade Images
The k3s-io/k3s Release CI should dispatch the k3s-io/k3s-upgrade repo, generating a tag there and triggering the CI to build images.
These images depend on the release artifact and can not be generated until after the k3s-io/k3s release CI completes.
This sometimes fails! Check the CI and if it was not triggered do the following:
This process will take some time but upon completion, the images will be listed here.
The k3s images will be published [here](https://hub.docker.com/r/rancher/k3s).
The upgrade images will be published [here](https://hub.docker.com/r/rancher/k3s-upgrade).
This sometimes fails! Check the CI and if it was not triggered do the following:
1. Create a release in the system-agent-installer-k3s repo
1. it should exactly match the release title in the k3s repo
1. the target is "main" for all releases (no branches)

7
docs/release/kubernetes-upgrade.md
View File

@ -196,7 +196,9 @@ Once CI passes and you receive two approvals, you may now squash-merge the PR an
Releases are kicked off and created by tagging a new tag.
To create a new release in Github UI perform the following:
1. Set title and tag according to the release version you're working on. E.g. v1.28.2-rc1+k3s1.
### In the case of a update to k3s, it should be incremented from `k3s1` to `k3s2`, for example, meaning the k3s version is being incremented.
1. Set title and tag according to the release version you're working on. E.g. v1.28.2-rc1+k3s1, if release only for k3s e.g v1.28.2-rc1+k3s2
2. Leave description blank.
3. Check the pre-release field.
4. Publish
@ -283,7 +285,8 @@ Once QA signs off on a RC:
2. Ensure prerelease is checked.
3. Publish.
4. Reiterate the previous checking processes and update KDM specifications accordingly with the GA release tags.
##### `24 hours after` CI has completed and artifacts are created:
5. CI has completed, and artifacts have been created. Announce the GA and inform that k3s is thawed in the Slack release thread.
##### `After 24 hours`:
1. Uncheck prerelease, and save.
2. Update channel server

7
docs/release/release.md
View File

@ -24,7 +24,7 @@ We made some new tags on the k3s-io/kubernetes repo, now we need to tell k3s to
1. The first part of cutting a release (either an RC or a GA) is to create the release itself, per [cut release](expanded/cut_release.md).
1. Then we need to update KDM, per [update kdm](expanded/update_kdm.md).
1. We create release images, per [release images](expanded/release_images.md).
1. We check the release images, per [release images](expanded/release_images.md).
1. Then we need to update or generate the release notes, per [release notes](expanded/release_notes.md).
## Create GA Release
@ -35,7 +35,7 @@ This will be tested one more time before the release is considered ready for fin
Follow the processes for an RC release:
1. [Cut Release](expanded/cut_release.md)
1. [Update KDM](expanded/update_kdm.md)
1. [Create Release Images](expanded/release_images.md)
1. [Check Release Images](expanded/release_images.md)
1. [Update Release Notes](expanded/release_notes.md)
Make sure you are in constant communication with QA during this time so that you can cut more RCs if necessary,
@ -45,7 +45,8 @@ When QA approves the GA release you can move into the finalization phase.
## Finalization
1. Update the channel server, per [channel server](expanded/channel_server.md)
1. Copy the release notes into the release, per [release notes](expanded/release_notes.md)
1. Copy the release notes into the release, make sure Release Notes already merged, per [release notes](expanded/release_notes.md)
1. CI has completed, and artifacts have been created. Announce the GA and inform that k3s is thawed in the Slack release thread.
1. Wait 24 hours, then uncheck the pre-release checkbox on the release.
1. Edit the release, and check the "set as latest release" checkbox on the "latest" release.
- only one release can be latest