(maint) - Set max_issues for changelog generator to 500 #1285
Conversation
Rakefile
Outdated
| @@ -53,6 +53,7 @@ if Bundler.rubygems.find_name('github_changelog_generator').any? | |||
| config.header = "# Change log\n\nAll notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) and this project adheres to [Semantic Versioning](http://semver.org)." | |||
| config.add_pr_wo_labels = true | |||
| config.issues = false | |||
| config.max_issues = 500 | |||
There was a problem hiding this comment.
After 500 issues, what happens? Is it the oldest ones that get dropped?
There was a problem hiding this comment.
actually, how does this even apply for this project, where github issues are disabled?
There was a problem hiding this comment.
No, nothing get's dropped, it just ignores anything past that. If they are already in the changelog they will stay there, but if something where to happen, i.e. their label where to change, they wouldn't be updated like they would be now.
There was a problem hiding this comment.
Are you sure? I can't reproduce that. Testing this behaviour is a bit tricky though as even if you set max_issues to a very small number, a minimum of 100 are fetched. https://github.com/github-changelog-generator/github-changelog-generator/blob/d801469b07932c3647fafa7fed2796fa3b9ebff4/lib/github_changelog_generator/octo_fetcher.rb#L17
There was a problem hiding this comment.
Yeh, we previously used this fix for apache, though it was accidentally stripped by a pdk update, so I'm confident it will cause no problems
There was a problem hiding this comment.
Have tested the fix and it worked: https://github.com/puppetlabs/puppetlabs-postgresql/actions/runs/1093892098
There was a problem hiding this comment.
ok. I'm guessing that anything that wasn't fetched happens to be older than 5.3.0 and is covered by what's in HISTORY.md
There was a problem hiding this comment.
Ah, no.
This work's separately from the HISTORY.md.
With the HISTORY.md it set's a hard end point, cover everything up to this and if something doesn't match what it retrieves, it changes it. As in, if you reach this point, stop.
This change however rather than setting a goal, makes it so that once it reaches the set amount of issues, it it stops looking any further and simply accepts what comes after that point is correct and doesn't need to be looked at. As in, if you travel this distance, stop.
The two are separate, but complementary.
I'm sorry if I'm not explaining it that well.
There was a problem hiding this comment.
I always thought the CHANGELOG.md was regenerated completely when github-changelog-generator was run.
So... I tested by setting max_issues to 100 (the smallest number that makes a difference since the issues are fetched in batches of 100). Existing entries get removed (unless they're part of HISTORY.md that just gets appended verbatim). See alexjfisher@123ab70
But I guess if this ever does become a problem then there's the solution. Just prepend some of the existing CHANGELOG.md to HISTORY.md as a workaround.
david22swan
force-pushed
the
maint/main/max_issues
branch
from
db5847f to
15a4318
Compare
|
Thank you @david22swan @alexjfisher |
Tests failures are from a known issue and unrelated to changes.