feat: automatic generation of release notes #35977
Conversation
GiteaBot
added
the
lgtm/need 2
github-actions
bot
added
modifies/translation
modifies/go
dawidgora
force-pushed
the
feat/automatic-generation-of-release-notes
branch
from
d36f97f to
f32b963
Compare
|
Also cc @techknowlogick for further review and help (#35976 (comment)) , in case you already have more discussions. |
|
In 1406ccc:
|
|
In followup PR, when I find some time I will implement additional configuration for this feature, like it is on GitHub: https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes |
Still many And #35977 (comment)
|
Ok, I made it less defensive now @wxiaoguang
We haven't, but @techknowlogick feel free to review my PR |
wxiaoguang
left a comment
wxiaoguang
left a comment
There was a problem hiding this comment.
TBH, still questions (only a quick look, not carefully look into backend code yet)
|
Thank you for your updates. I've been very busy lately, so don't have enough time to do a full test and review at the moment. Meanwhile other maintainers can help to review. |
|
It seems no commits listed when I tested it locally. |
@lunny It only works for pull requests. Did you have them, or just commits? It mimics the Github behavior. |
Okay, I see. I assume it currently collects commits. In the future, we could consider adding an option to collect either commits or pull requests. |
GiteaBot
added
lgtm/done
It's practically useless to me when it does not include commits without a associated pull request, as I think that's a very common scenario, for example when the repo owner does fixups etc. But if it matches GH (it seems so), I won't block on it. |
|
A quick test, UI is broken 
Update: fixed in new commits |
|
And the new input & button take too much space IMO, maybe need some new design 
|
|
A UX problem: If user has input many message in the textarea, then click the "Generate release notes" button, then their work is lost and no way to undo? Is it better to "append" but not "replace"? |
| func parseSemanticVersion(tag string) *version.Version { | ||
| tag = strings.TrimSpace(tag) | ||
| tag = strings.TrimPrefix(tag, "v") | ||
| tag = strings.TrimPrefix(tag, "V") | ||
| v, err := version.NewVersion(tag) | ||
| if err != nil { | ||
| return nil | ||
| } | ||
| return v | ||
| } |
There was a problem hiding this comment.
Should it support tag name with fields? For example: releases/v1.0
There was a problem hiding this comment.
Yeah, good idea. What would you say if, in such a case, it needed to match the same field as the currently created tag?
For example, if we are creating a new release with the tag release/v1.1.0, it would look for release/v1.0.0, but not for nightly/1.0.0.
Or maybe it’s overengineering, and we should keep it simple. Let me know how you see it, and I can adjust the logic.
There was a problem hiding this comment.
Maybe we should remove the "Auto" feature, and always let end users choose?
We can make a best guess (only compare the last field) to make the latest tag to be selected by default on the UI. It could also simplify the code.
And users can clearly know what would happen
There was a problem hiding this comment.
Ok, I'll do it like this. I hope to find some time today, but can't promise
I can implement that in the following PR, along with other improvements. But first, I'd like to have this one merged. |
Fine with me. |
|
Branch needs to be updated and it will likely have some new typescript issues because we enabled |
Just tested with GitHub, it "resolves" this problem by disabling the generation when the textarea is not empty: 
ps: GitHub has more logic for the "generation", I didn't mean that we must follow GitHub, while I think at least we should avoid surprising end users. Maybe using a modal dialog is better, then the UI can be simplified and more options can be added in the future (for example: add a checkbox to also add commit messages without a PR) |
5 participants
Add GitHub-style automatic release notes generation
Screenshots