docs: describe the release process#131
docs: describe the release process#131fmuyassarov wants to merge 1 commit intokubernetes-sigs:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: fmuyassarov The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
michaelasp
left a comment
There was a problem hiding this comment.
Lgtm overall, should we wait for #130 to land before merging the docs?
Signed-off-by: Feruzjon Muyassarov <feruzjon.muyassarov@est.tech>
c0d84cb to
cfbe90e
Compare
gauravkghildiyal
left a comment
There was a problem hiding this comment.
Thanks @fmuyassarov. This is gonna be really helpful.
I've left a few suggestions.
| to help with release notes generation. Among several other helpful features, | ||
| it can help extract release notes from the PR description. | ||
| DRANET releases both a container image and a Helm chart as OCI artifacts, both | ||
| promoted through the Kubernetes image promotion pipeline. |
There was a problem hiding this comment.
Can we please link to the standard process which we are following for future references https://github.com/kubernetes/k8s.io/blob/main/registry.k8s.io/README.md
| --github-repo dranet \ | ||
| --branch main \ | ||
| --start-rev vX.Y.Z-1 \ | ||
| --end-rev vX.Y.Z \ |
There was a problem hiding this comment.
Should we keep Generate release notes section as the second step, given we've not yet generated this tag?
| ``` | ||
| Review and edit `release-notes.md`. | ||
|
|
||
| ## 2. Push a release tag |
There was a problem hiding this comment.
Before creating the tag, we'd like to create a release branch. Let's focus on a major/minor kind of release (and appropriately name this section because the steps for a patch release could slightly differ)
For example, we create a new release branch release-1.1 and then a corresponding tag within this branch v1.1.0.
|
|
||
| ## 3. Cloud Build produces staging artifacts | ||
|
|
||
| Cloud Build runs `make ensure-helm release`, which: |
There was a problem hiding this comment.
(Based on the outcome from the other question in #130 (comment), lets update this, or resolve the comment if no action is needed)
| "sha256:<CHART_DIGEST>": ["X.Y.Z"] | ||
| ``` | ||
|
|
||
| Once the PR is merged, the `post-k8sio-image-promo` postsubmit job in kubernetes/test-infra will promote both artifacts from `gcr.io/k8s-staging-networking` to `registry.k8s.io/networking`. |
There was a problem hiding this comment.
nit: Can we link to https://testgrid.k8s.io/sig-k8s-infra-k8sio#post-k8sio-image-promo as well? (I assume this is the correct one right)
|
|
||
| ## 7. Publish the GitHub Release | ||
|
|
||
| Publish the release notes prepared in step 1 as a [GitHub Release](https://github.com/kubernetes-sigs/dranet/releases/new) against the tag. At this point all artifacts are available at `registry.k8s.io` and the release is safe to announce in [#wg-device-management](https://kubernetes.slack.com/archives/C0409NGC1TK) Slack group. |
There was a problem hiding this comment.
If we are include working groups, let's include sig-network as well :)
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Add a release process docucment
Which issue(s) this PR is related to:
Partially related to #128
Special notes for your reviewer:
Depends on #130
Does this PR introduce a user-facing change?