ci: improved changelog generator #2610
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2610 +/- ##
======================================
Coverage 8.04% 8.04%
======================================
Files 69 69
Lines 13335 13335
Branches 6601 6601
======================================
Hits 1073 1073
+ Misses 11252 11246 -6
- Partials 1010 1016 +6
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
Thanks for this, but we're just going to use GitHub's changelog generator for now. Let's see how that goes for a few releases before adjusting. I've been burned by these kind of actions before... becoming unmaintained and leaving me to scramble to create my own changelog parser. This one seems popular enough where that might be less likely to happen. I guess if this were to be implemented it would need to happen in the setup-release-action. |
|
@ReenigneArcher I'm mostly testing right now, the idea is to reimplement in our own actions, but I want first to test if they actually get what I want It's not even a real PR, I'm editing in the browser each commit |
|
Understood. For reference: this is the current process to convert a release to stable.
That's all there is. At that point, the changelog will updated and be saved to the changelog branch in markdown format. The action that updates that, loops over all releases in the repo to create the changelog. That file is consumed by the docs, but could be used in other places as well. If a typo or mistake was made in the release body, the release can be re-edited and the changelog will update again. Since the only thing these changes would save is |
|
This is an example of what would be generated if we released today. I really like the "New Contributors" section as it gives credit and hopefully encourages people to keep contributing.
|
|
@ReenigneArcher the automation is not exactly the main point of my experimentation, I'd like to create changelog automation for pre-release versions, but I feel that manually like you do feels better for stable releases. My end goal is a good categorization system, to break each kind of PR/commit into it's own category, sort and merge duplicated items (same dep updated twice), and it then fork the current changelog builder to add this layer, but first I want something close enough to avoid building from scratch, I don't want a drop-in replacement. Sorry for choking the pipeline with this, it was the easiest way to test that it would work in our constraints, in my fork I don't have the same data to see what I want. |
|
The simplest approach is to make 2 api calls. 1 to get the latest release, and 1 to generate the release notes (passing in the latest release as the
This will make pre-release notes mimic stable release notes. |
|
If you got here, because of my ping, sorry, I made a mistake |
|
@ReenigneArcher it's quite polluted and have some issues, but it was auto generated and organized, so I can use this as a base to rewrite something like that: |
|
Experiment done for now, I'll continue with something next month or so, writing from scratch using the findings I got here. |
|
Thanks, I'm also planning to improve the pre-release initial change body in the next week or so. |
This is implemented now. If you'd still like to work on categories, that would be cool. We can accomplish it via labels. https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes |
Description
Screenshot
Issues Fixed or Closed
Type of Change
.github/...)Checklist
Branch Updates
LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.