UPDATE: Release Document #1133
UPDATE: Release Document #1133
Conversation
RELEASE.md
Outdated
| ## Automated Verification Processes. | ||
|
|
||
| * Check that dependencies release images exist for stated version | ||
| * Check that the git tag does not all ready exist for the stated release. | ||
| * Automated test, install via OLM and ensure the correct images are on cluster. | ||
| This should handle most of [Verify OLM Deployment](#verify-olm-deployment), except the checking of the logs. | ||
| * Ensure all required fields are stated in the `release.toml`. |
There was a problem hiding this comment.
Tracking checks that I believe should be part of the release process. This section may not make it to the final version.
There was a problem hiding this comment.
Yeah these look good and IMO should be added as tasks to the overall top level issue
There was a problem hiding this comment.
Sure, that makes more sense than making the note here.
|
How long do you want to keep it as draft? Until the changes are ready or do you want it to be a full PR before that? |
|
|
||
| 3. Run the GHA [Release operator](https://github.com/Kuadrant/kuadrant-operator/actions/workflows/release.yaml); make |
There was a problem hiding this comment.
What is this release operator workflow doing high level?
I think we should have one section for minor releases and other one for patch releases.
minor releases
- create
kuadrant-vX.Y.0branch - create
kuadrant-vX.Y.0-minorbranch - Open PR against
kuadrant-vX.Y.0branch updating kuadrant version and dependency versions (that would trigger tests) - Once approved, tag it.
- The tag would trigger GHA workflow to build images and create release notes in GH. (no tests run), deploy new release in operatorhub (maybe not for this time.. in the future), deploy helm charts.
patch releases
- create
kuadrant-vX.Y.Z-patchbranch - Open PR against
kuadrant-vX.Y.0branch updating kuadrant version and dependency versions (that would trigger tests) - Once approved, tag it.
- The tag would trigger GHA workflow to build images and create release notes in GH. (no tests run), deploy new release in operatorhub (maybe not for this time.. in the future), deploy helm charts.
Sounds reasonable? No need to deal with release implementation details. My design goal is that anyone, with no tech knowledge requirements of kuadrant, is able to release kuadrant.
There was a problem hiding this comment.
Looks like minor and patch release procedures are pretty much the same.. maybe we should merge them in one single... IDK 🤷
There was a problem hiding this comment.
Yeah I think that is fine as long as we call out the key difference of using the existing release branch for a patch
There was a problem hiding this comment.
I think the two can be rolled one. There should be no difference in the cutting of release for patches over minor versions. The only thing is the ensuring of the kuadrant-vx.Y.0 branch, and creation if missing.
|
|
||
| This example of the `release.toml` file uses tag `v1.0.1` as reference. | ||
|
|
||
| ```toml |
There was a problem hiding this comment.
The format LGTM. What tools could we leverage from GHActions (bash) or Makefile to read those?
There was a problem hiding this comment.
You can use yq, however I have notice support for list is not native and you need to pass the -oy flag.
RELEASE.md
Outdated
| ## Automated Verification Processes. | ||
|
|
||
| * Check that dependencies release images exist for stated version | ||
| * Check that the git tag does not all ready exist for the stated release. |
There was a problem hiding this comment.
| * Check that the git tag does not all ready exist for the stated release. | |
| * Check that the git tag does not already exist for the stated release. |
Adjust the release document to suit the new release process. Signed-off-by: Jim Fitzpatrick <[email protected]>
Boomatang
force-pushed
the
release_process/docs
branch
from
43adc05 to
aa9d1bb
Compare
Adjust the release document to suit the new release process.