Autorelease functionality #304
Conversation
|
https://github.com/toolmantim/release-drafter/commit/dfc1c77d8720475b9a89f4e619675dbf3db85c0d.patch @JimNero009 |
|
Thanks for the tip @jetersen -- done that now. |
index.js
Outdated
| context.repo({ | ||
| release_id: releaseId, | ||
| draft: false, | ||
| name: thisVersion, // TODO - how should name and tag_name behave here? |
There was a problem hiding this comment.
@jetersen What is the kind of thing you would like to see here? I'm starting to think that this has a fundamental flaw, and that I actually need to go back a few steps and interrupt the templating process for the name and tag variables to make sure they correspond to the version that is just about to be released?
There was a problem hiding this comment.
From above you should have:
https://github.com/toolmantim/release-drafter/blob/4e0c93d4a6c5296d865ca2dcd1e4c54d9058c531/index.js#L71-L76
you should have access to releaseInfo.name and releaseInfo.tag
Perhaps your incrementVersionBasedOnLabels should update the releaseInfo.tag?
There was a problem hiding this comment.
Ah, of course! Not sure how I didn't see that.
So yeah -- when generating the release info, I can just hook right into that and get it to resolve to different version numbers based on labels. Shouldn't be too difficult... 😅
index.js
Outdated
| context.repo({ | ||
| release_id: releaseId, | ||
| draft: false, | ||
| name: thisVersion, // TODO - how should name and tag_name behave here? |
There was a problem hiding this comment.
From above you should have:
https://github.com/toolmantim/release-drafter/blob/4e0c93d4a6c5296d865ca2dcd1e4c54d9058c531/index.js#L71-L76
you should have access to releaseInfo.name and releaseInfo.tag
Perhaps your incrementVersionBasedOnLabels should update the releaseInfo.tag?
|
Hi @JimNero009. I think that the autorelease functionality you're planning here is fantastic. However, the reason I found this PR is for a different reason. I'm super excited about the idea of having labels determine what part of the version gets incremented. (After I found this PR, I also ran across #256 (comment) so I'm linking it just to have the cross-references to help people searching about this feature). I have one quick question. Is the conditional incrementing a feature that will be tightly coupled with the autoreleases or would I be able to use the label-based increments without having the auto-publish functionality enabled? Keep up the great work! |
|
We could easily decouple auto-release from label increment. |
|
Indeed -- we can probably just make https://github.com/toolmantim/release-drafter/pull/304/files#diff-168726dbe96b3ce427e7fedce31bb0bcR26-R30 a more general config block that contains an auto-release flag, rather than the config block containing all information pertinent only to an auto-release |
|
Upvoting this feature, would be amazing to have this |
|
Thanks for the replies. I'm looking forward to it. It'll make my release cycle dead simple. |
|
@jetersen @IncPlusPlus @herecomesjaycee @JimNero009 Thank you guys! I would love to see these features implemented. I'm also upvoting this feature 👍 |
|
The commit before this message decouples the templating-by-labels and the auto-release functionality. |
|
@jetersen Think the code is in a decent place again, would appreciate another look. If all looks good with you, I'll do a proper integration test tomorrow. |
|
Any update on this? Would love this feature too 🙏 |
|
I do still need to properly test this on a real repository, as it were, just to add confidence to the automated testing. Other than that, I think it's 'just' a code review away! |
|
Hey @JimNero009, thanks a lot for the effort! I've put some of my thoughts about this in the issue here: #141 (comment). Please let me know what you think of this idea. |
|
Has the publish functionality been implemented? |
|
@JimNero009 #546 will most likely fit the bill, we are removing the constraint that we had placed on GitHub actions 😆 |
Allow the release drafter to auto-publish the releases it drafts, if a user so wants.
Works by inspecting labels on the PRs that have gone into making the draft, then publishing the draft with the version that best fits.