-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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.
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
Use a release notes generator #965
Comments
Hey there, Been stalking this repo for a while. This one seems interesting to me :) Would using kubernetes release notes (as suggested) be suitable or did you have something else in mind as well? |
I did take a look at release-notes. I think the only draw back is that it requires the GitHub API token. I can't think of a general way (e.g. anyone can publish the release notes with out access to the GitHub token). Would be nice if release-notes had an option to look at the local git history instead of querying GitHub :( Thoughts? |
It parses the PR body for a |
Github actions (if we do move to that), provide tokens |
I'd be happy to take this up then 🤗. Is there any existing documentation on the current release process? |
I do the following steps:
|
@j0n3lson assigned this to you! 🚀 |
I experimented with a few options today: Experimented withNightapes/go-semantic-releasePros
Cons
Kubernetes Release NotesPros
Cons
Honorable Mentionssemantic-release/semantic-releasePros
Cons
I didn't mess around with this because I didn't feel like messing with nodejs which can be wonky to install sometimes. Summary
|
I think also with Nightapes/go-semantic-release we can easily integrate with the exiting Github Actions setup (I'm no expert here). We'd probably need another action to run on merge and it would:
If we go this route we would want: 2.1 Integrate with existing workflow [Make it better] What do you all think? |
I think the thing we're mostly after is something that compiles release notes, version tagging et al and actually performing the release is somewhat secondary objectives (perhaps I am wrong, as I've been pretty hands off). My vision of what I would want (but I am not the one making the releases so it's irrelevant to some extent). Do any of the tools do something like that? |
The Kubernetes release notes generator tests for a OTOH we could add another option for the release notes generator to use a template as input, which is an idea I had in the past but did not implemented it right now (because there were no external consumers of this tool. |
I thought this project might like using labels vs parsing commit messages which seems to agree with what @saschagrunert pointed to. From your description it seems like we'd need something that enforces a rule like: All PRs must have at least one label {skip-release-notes, release-note-bugfix kr release-note-feature}. It would be used at pull request time (and possibly at merge time).
Kubernetes and semantic-release support those use-cases ootb.
I'll look into filtering based on labels in the direction of writing a tool around |
From a use case / generating perspective: In the k8s release notes generator you can specify an empty notes block or something like |
Hey everyone. So I'm a little confused on how to get started/make progress here :( There seems to be two use-cases here:
I guess my main question is would the default output of For either case we'd need to do the following to even use the tool:
The CHANGELOG.md currently follows a simple Added, Removed, Changed format. If you all are really attached to this format then what @saschagrunert suggested (e.g. get notes using I'm I thinking about this the right way? |
The output from
👍 give me the list and I can do it now?
This is a distinct task - so I cut a new issue => #1007
I would described myself as "fond of" rather than "attached" 🙂 Fully automating the releases is more important to me than keeping the Added, Removed, Changed format.
Yep 🚀 |
What if we agree on a set of kinds for every PR, where multiple kinds per PR are possible as well, for example:
Then we could create the notes via the tool, parse the JSON and print it into our own preferred output, like: Welcome to urfave/cli version x.y.z
# Features
- Adding a shiny new feature which solves all our problems (PR #89317, @lynncyrin)
# Bugfixes
… |
Love this idea ✨ |
I ended up going with @saschagrunert earlier suggestion (support templates in release-tool). I have a PR#1008. With that PR we can specify whatever format we need in the template (and skip bits we don't need like the SIG stuff). I experimented with wrappers around release-notes as suggested but cried a bit inside because of the duplicate code. PTAL and let me know what you think! @lynncyrin Any objection with using the PR template they use in kubernetes (see my PR)? The minimum need is to have either a "release-notes" or "Does this PR introduce a user-facing change?:" block in order to get notes. However, release-notes makes some assumptions about the PR body (I saw some regexps) and it might just be simpler to do as the Romans do here. |
No objections, totally ship it! |
I think I know what you mean 😊
Edit: Saw the PR in k/release, I think that is the best approach 👍 |
Yep. That's the one I saw before. I filed issue#1019 on k/release to discuss migrating to the same template-based approach approach as PR#1008. |
In terms of this issue, the only think left to do is:
Missing anything else? |
We can think about adding a GitHub action to generate the notes, but I'm not sure if we want to do that. |
This definitely sounds like something we'd want to do 👍 |
Finally pushed it. Got busy with taxes and perf and what not. Hopefully can merge it soon :) |
Just a quick update.
```release-notes ``` I should be able to give a demo once my PR get's merged in k8s/release... |
Github has now automated release note generator: https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes |
I'd like to call this done since we've been using the GitHub automatic release notes for many releases. |
surfaced via #963 (comment)
The text was updated successfully, but these errors were encountered: