-
Notifications
You must be signed in to change notification settings - Fork 24
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
Fixes #52: added support for automatically generated release notes. #53
Fixes #52: added support for automatically generated release notes. #53
Conversation
…tes. - default behavior: delegate to GitHub - if `<description>` is supplied via plugin configuration, will be prepended to the notes autogenerated by GitHub.
@@ -207,7 +207,7 @@ | |||
<dependency> | |||
<groupId>org.kohsuke</groupId> | |||
<artifactId>github-api</artifactId> | |||
<version>1.317</version> | |||
<version>1.318</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Support for auto-generated release notes was added in this very recent version.
@@ -82,7 +82,7 @@ public class UploadMojo extends AbstractMojo implements Contextualizable{ | |||
/** | |||
* The release description | |||
*/ | |||
@Parameter(property = "project.description") | |||
@Parameter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest to drop project.description
- from my experience, in 99% of the cases it is included in POM, but when looking at the release page on Github, we already have a context of what this codebase is about. So now that release notes will be generated, it might make less sense to have a repetitive project.description
part on top of that.
Should anyone still need it, there is always a way to say in the plugin configuration:
<description>${project.description}</description>
@@ -189,6 +189,7 @@ public void execute() throws MojoExecutionException { | |||
if (release == null) { | |||
getLog().info("Creating release "+releaseName); | |||
GHReleaseBuilder builder = repository.createRelease(tag); | |||
builder.generateReleaseNotes(true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was on the fence between having it in the else
branch (that is, when description is null) vs. always adding it, and decided that GitHub is doing a better job in most of the cases. Any customization can still be added on top as specified in the previous comment.
@jutzig would very much appreciate a review. Thank you. |
hi @jutzig , would be great to hear your feedback on this one. |
Hi @anenviousguest What do you think about adding the first picture from your pull request as an example to the readme and include the link to automatic release notes description? I don't want to use the picture without permission, since it includes your user handle... |
Hi @jutzig
I guess so, at least on the API page they do mention that YAML file.
No prob at all, let me update the README then... |
Hi @jutzig , I updated the README with your link and put a screenshot there as well. |
Hi @jutzig , would appreciate a feedback on this one, thanks a lot. |
Thank you, looks great. I'll prepare a release now |
<description>
is supplied via plugin configuration, it will be prepended to the notes autogenerated by GitHub.