Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update Release Drafter details and documentation #1384

Merged
merged 2 commits into from
Mar 4, 2020
Merged

Update Release Drafter details and documentation #1384

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
04e088f
Change release drafter draft name to 'Draft'
ANeumann82 Mar 3, 2020
92a5a07
Merge branch 'master' into an/release-drafter-details
ANeumann82 Mar 3, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions .github/release-drafter.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
name-template: 'kudo-v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
name-template: 'Draft'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it make sense to assume we will have more than 1 draft?

  1. 1 for master (which will be $NEXT_MINOR_VERSION)
  2. 1 or more for release branches (i.e., releases/0.10 which will be $NEXT_PATCH_VERSION)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

tag-template: 'draft'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as ^^

categories:
- title: '🚀 Highlights'
labels:
Expand All @@ -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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👏


## Changes

$CHANGES

## Docker images

- `docker pull kudobuilder/controller:latest`
- `docker pull kudobuilder/controller:$NEXT_PATCH_VERSION`
- `docker pull kudobuilder/controller:EDITME`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

3 changes: 3 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do you think of adding release/bugfix and having a category of bugfixes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


- For a piece of work that takes >3-5 days, pair with somebody
- When you pair with somebody, don't forget to appreciate their work using [co-authorship](https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors)
Expand Down
2 changes: 1 addition & 1 deletion RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

additionally... after using the draft for the release... delete the draft.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

1. Send an announcement email to `[email protected]` with the subject `[ANNOUNCE] Kudo $VERSION is released`
1. Create a PR against [kudobuilder/kudo.dev](https://github.com/kudobuilder/kudo.dev) with an according [blog post](https://kudo.dev/internal-docs/blog-index.html#release-posts).
1. Run `./hack/generate_krew.sh` and submit the generated `kudo.yaml` to https://github.com/kubernetes-sigs/krew-index/.
Expand Down