Update Release Drafter details and documentation #1384
Conversation
Add information about release-labels Add information to release process Signed-off-by: Andreas Neumann <[email protected]>
ANeumann82
requested review from
alenkacz,
gerred,
kensipe,
nfnt and
zen-dog
as code owners
.github/release-drafter.yml
Outdated
| @@ -1,5 +1,5 @@ | |||
| name-template: 'kudo-v$NEXT_PATCH_VERSION' | |||
| tag-template: 'v$NEXT_PATCH_VERSION' | |||
| name-template: 'Draft' | |||
There was a problem hiding this comment.
does it make sense to assume we will have more than 1 draft?
- 1 for master (which will be $NEXT_MINOR_VERSION)
- 1 or more for release branches (i.e.,
releases/0.10which will be $NEXT_PATCH_VERSION)
There was a problem hiding this comment.
Yeah, that may be possible. We'd have to look into the when we're doing patch releases. At the moment the release drafter only watches the master-branch, so we only get the one draft, but we could set it up for release-branches as well.
I've changed the tag-template a little bit in this PR, as i'm not totally sure how GitHub works in this regard. If we use the actual tag template for the release, it might be that go-releaser wouldn't update the body of the ReleasePage and just append the released files.
I think we have to play around a little bit with that in the next releases.
.github/release-drafter.yml
Outdated
| name-template: 'kudo-v$NEXT_PATCH_VERSION' | ||
| tag-template: 'v$NEXT_PATCH_VERSION' | ||
| name-template: 'Draft' | ||
| tag-template: 'draft' |
| @@ -9,11 +9,15 @@ categories: | |||
| - 'release/breaking-change' | |||
| change-template: '- $TITLE @$AUTHOR (#$NUMBER)' | |||
| template: | | |||
| This is a draft for the next release. | |||
|
|
|||
| Please do not edit this file directly, use it as a template in the next release. | |||
.github/release-drafter.yml
Outdated
| ## Changes | ||
|
|
||
| $CHANGES | ||
|
|
||
| ## Docker images | ||
|
|
||
| - `docker pull kudobuilder/controller:latest` | ||
| - `docker pull kudobuilder/controller:$NEXT_PATCH_VERSION` | ||
| - `docker pull kudobuilder/controller:EDITME` |
There was a problem hiding this comment.
lets pull the whole docker section out (as in #1379)
This is a template to augment the goreleaser release data. goreleaser includes this data and I would propose is the release authority on data. What we need from this process is release highlights and breaking changes... everything else looks like it will be lost.
# Conflicts: # .github/release-drafter.yml
| @@ -27,7 +27,7 @@ The official binaries for KUDO are created using [goreleaser](https://goreleaser | |||
| 1. Ensure you are logged into Docker hub and have rights to push to kudobuilder. | |||
| 1. Tag repo with expected release `git tag -a v0.2.0 -m "v0.2.0"` && push tag `git push --tags`. | |||
| 1. Invoke goreleaser `goreleaser --rm-dist`. | |||
| 1. Update the GH release with Release highlights and a changelog. | |||
| 1. Update the GH release with Release highlights and a changelog. There is a draft that contains categorized changes since the last release, use this as a template. It provides categories for highlights and breaking changes, the issues there should get a more detailed description. | |||
There was a problem hiding this comment.
additionally... after using the draft for the release... delete the draft.
There was a problem hiding this comment.
I don't think it's necessary, as the release drafter would overwrite the draft with the new changelog on the next landed PR, but i've added a comment that the draft can be deleted afterwards.
| @@ -90,6 +90,9 @@ This is a set of practices we try to live by when developing KUDO. These are jus | |||
| - Since KUDO is developed in multiple timezones, try to keep the PR open for everyone to be able to see it (~24h, keep in mind public holidays) | |||
| - We prefer squash commits so that all changes from a branch are committed to master as a single commit | |||
| - Before you merge, make sure your commit title and description are meaningful. Github by default will list all the individual PR commits when squashing which are rarely insightful. We aim for a clean and meaningful commit history. | |||
| - Labels: If your PR includes either **breaking changes** or should get additional attention in the release, add one of these label: | |||
| - `release/highlight` For a big new feature, an important bug fix, the focus of the current release | |||
| - `release/breaking-change` For anything that breaks backwards compatibility and requires users to take special care when upgrading to the new version | |||
There was a problem hiding this comment.
what do you think of adding release/bugfix and having a category of bugfixes?
There was a problem hiding this comment.
I've added it, although I'm a bit hesitant to add too many categories. I'm not sure if we want to categorise all our PRs, it may be a goal at some point. Let's see how we're going to use it.
|
also... WDT of |
Yeah, i like it, added it to the template. |
Add information about release-labels Add information to release process Signed-off-by: Andreas Neumann <[email protected]> Signed-off-by: Thomas Runyon <[email protected]>
Change release drafter draft name to 'Draft'
Add information about release-labels
Add information to release process
Signed-off-by: Andreas Neumann [email protected]