Repository navigation
perf: decrease runtime for 3K+ commit history #722
Description
Hello, I'm trying to integrate this tool to our big repo (~3k commits) and the changelog generation takes a lot of time (40m). Is there a way to generate the changelog incrementally (once generated for all the commits) that just appends the missing part of it without rewalking the entire git tree?
Activity
bernardcooke53 commentedon Oct 13, 2023
Hey @rdbisme - there isn't currently, that gets really tricky when dealing with multiple branches where some changes are/aren't on the current branch. I think it could be possible to do with a comment in the changelog indicating the "last" version that it was generated for, but could still be broken pretty easily with a custom template.
I think it's potentially doable but a non-trivial amount of work
Sieboldianus commentedon Oct 19, 2023
I agree. I had a carefully crafted CHANGELOG that got overwritten since v8 was release. I wish there was such a
lastoption to indicate a commit below which Semantic-release should not delete entries. This could also be used to once-in-a-while walk through the changelog and manually clean things up.github-actions commentedon May 27, 2024
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
codejedi365 commentedon May 27, 2024
No update here yet, however, I have been evaluating performance improvements across the project and this example is one that I use to theorize improvements.
My latest idea is to add caching of the parsed commit objects which in theory should never need to be parsed again unless the configuration significantly changes or you rebase the entire project. This should decrease all subsequent runtimes with caching set up in the CIs.
I will keep evaluating to see if a partial git tree evaluation can be added but as it was stated above, definitely a lot of work to accomplish.
github-actions commentedon Jul 27, 2024
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
codejedi365 commentedon Jul 27, 2024
Unfortunately, no movement here yet
28 remaining items
github-actions commentedon Apr 9, 2025
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
codejedi365 commentedon Apr 10, 2025
Still in backlog
github-actions commentedon Jun 9, 2025
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
codejedi365 commentedon Jul 4, 2025
Currently more significant improvement in work likely for the next major release. I would be curious if you have already seen an improvement in speed lately?
Also with your answer, please let me know if you are using the GitHub Docker Action or are you using it directly. You will find that if you use python-semantic-release directly (as opposed to the Docker action) you will get significant GitHub Actions workflow execution time decreases.
github-actions commentedon Oct 4, 2025
It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
codejedi365 commentedon Oct 6, 2025
Still in backlog
github-actions commentedon Jan 5, 2026
It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?