Description
Bug Report
Description
First of all, thank you for a great tool, you did an amazing work!
I have a usual flow with GitHub action that is running after the merge (exactly the one that is described in documentation). And it looks like in case of merge commits it can produce empty release and changelog, but still bump a version.
I have main
branchand
feature` branch. The history looks like this
* v1.2.0 release (main)
* Merge `feature into `main`
| \
| * Merge 'main' into 'feature' to get latest changes (feature)
| / |
| |
* | v1.1.0 release (main)
* | Some commit in main
| |
| * feat: My new feature (feature)
| /
|
Expected behavior
v1.2.0
release is created, release contains feat: My new feature
commit in changelog and release.
Actual behavior
v1.2.0
release is created, but CHANGELOG.md and GitHub release are empty, they don't contain feat: My new feature
, just blank
## v1.2.0 (2025-05-23)
Environment
- Operating System (w/ version): Ubuntu 25.04
- Python version: 3.10
- Pip version: 25.1.1
- Semantic-release version: 9.21.1
- Build tool (w/ version): None
Configuration
Semantic Release Configuration
[tool.semantic_release]
version_toml = ["pyproject.toml:project.version"]
[tool.semantic_release.changelog]
mode = "update"
Additional context
As I understand, the problem is not in python-semantic-release
directly; the problem is the git log
output format. Even with topo_order=True here, it still puts my feat: My new feature
commit before the v1.1.0 release
commit in the history. It looks like after the Merge 'main' into 'feature' to add the latest changes
commit, the git log
command decided to show commits from main
before showing commits from feature
.
Why the PR title mentions inconsistency is because in the version resolving logic, the _traverse_graph_for_commits() function returns the correct list of new commits since the last release.
As a result, the version is calculated correctly, but there are no new commits in the release history, so the changelog and release notes are empty.
An obvious idea would be to use _traverse_graph_for_commits()
-like logic in ReleaseHistory.from_git_history() to get unreleased
commits. But I assume it's not that simple, or it would have been implemented this way already.
I'm happy to provide more info or prepare a PR if you have an idea of how to deal with this behavior.