This bug report has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.

I am also having this issue when running semantic-release changelog locally. Does anyone have a workaround?

This bug report has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.

We also have this issue. I can reproduce this in an new repo:

setup.cfg

[semantic_release]
branch = main
version_variable = version.py:__version__
build_command = false
upload_to_repository = false

version.py

__version__ = "0.0.0"

Command Output

$ semantic-release print-version --patch
0.0.1
$ semantic-release changelog --patch -v DEBUG
debug: get_current_version_by_config_file('-beta.')
debug: Parsing current version: path=PosixPath('version.py') pattern='__version__ *[:=] *["\\\'](\\d+\\.\\d+(?:\\.\\d+)?)["\\\']' num_matches=1
debug: Regex matched version: 0.0.0
debug: get_current_version_by_config_file -> 0.0.0
debug: get_previous_version('0.0.0')
debug: Checking commit be37c8c6aa2a1b6f6068c0aa4e7477f69f36959f
debug: Checking commit dfeed23de3b7618bcc5282ac2661521ed98af5bf
debug: get_last_version(['0.0.0', 'v0.0.0'], omit_pattern=None)
debug: generate_changelog(None, '0.0.0')
debug: generate_changelog -> {'breaking': []}
debug: get_repository_owner_and_name()
debug: get_repository_owner_and_name -> ('mtnu', 'release-test-2')
debug: markdown_changelog('mtnu', 'release-test-2', '0.0.0', {'breaking': []}, header=False)
debug: markdown_changelog ->

So Changelog Output is empty. Am i missing some config?

Complete Test Changelog:

commit be37c8c6aa2a1b6f6068c0aa4e7477f69f36959f (HEAD -> master)
Author: Martin Neubert <martin.neubert@companymail.com>
Date:   Mon Apr 4 10:02:22 2022 +0200

    feat(logging): added logs for failed signups

commit dfeed23de3b7618bcc5282ac2661521ed98af5bf
Author: Martin Neubert <martin.neubert@companymail.com>
Date:   Mon Apr 4 09:49:25 2022 +0200

    initial release

Python and PIP Packages versions

$ python --version
Python 3.9.2

$ pip list
Package                 Version
----------------------- ---------
bleach                  4.1.0
certifi                 2021.10.8
cffi                    1.15.0
charset-normalizer      2.0.12
click                   8.1.2
click-log               0.4.0
colorama                0.4.4
cryptography            36.0.2
docutils                0.18.1
dotty-dict              1.3.0
gitdb                   4.0.9
GitPython               3.1.27
idna                    3.3
importlib-metadata      4.11.3
invoke                  1.7.0
jeepney                 0.8.0
keyring                 23.5.0
packaging               21.3
pip                     20.3.4
pkg-resources           0.0.0
pkginfo                 1.8.2
pycparser               2.21
Pygments                2.11.2
pyparsing               3.0.7
python-gitlab           3.3.0
python-semantic-release 7.27.1
readme-renderer         34.0
requests                2.27.1
requests-toolbelt       0.9.1
rfc3986                 2.0.0
SecretStorage           3.3.1
semver                  2.13.0
setuptools              44.1.1
setuptools-scm          6.4.2
six                     1.16.0
smmap                   5.0.0
tomli                   2.0.1
tomlkit                 0.10.1
tqdm                    4.64.0
twine                   3.8.0
urllib3                 1.26.9
webencodings            0.5.1
wheel                   0.37.1
zipp                    3.8.0

I don't know for sure yet, because I haven't had time to systematically investigate, but I think this behavior is fixed after you merge your branch to main/master on github. Once I merged one PR with the new python-semantic-release config in it, and made a tag, then everything seemed to work.

Again, haven't investigated systematically yet, just happened to notice it.

This bug report has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.

Could it be, that the version is looked up in commit messages instead of tags?

From what I understand, the code is reading the commit-messages and using the one containing the from_version as well as the one containing the to_version. So, if your commit-history does not contain any commit-messages (usually generated by python-semantic-release as well) containing these versions, the changelog cannot determine those commits and therefore does not report any commits.
Since the whole versioning is happing based on tags (if configured) this should be done for the changelog as well, if I understand this correctly. Can anybody confirm this?

This bug report has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.

Can anybody confirm this?

@triplem, I can confirm your investigation. I came to the same conclusion. I dug through the code and noticed that the changelog code semantic_release.history.logs.generate_changelog():105 checks explicitly for a commit with the to_version number in the commit_message. If latest version is not found, then it burns through all the commits until there are no more. Since it is never found it returns with an empty changelog dictionary {"breaking": []}.

This definitely seems like a bug to me since this is incompatible with the semantic_release configuration options of version_source equals tag or tag_only. It seems to me this function was created based on the default option of version_source = "commit". My recommendation for a fix is to (1) integrate in the version_source configuration value as a control flow mechanism for how to find the latest commit or (2) use tags as the initial detection mechanism (it's more direct) and use commit parsing as secondary. In either case, to implement commit-finding with tags, the latest commit can be located via list(reversed(repo.tags)) -> "List[git.TagReference]". git.TagReference objects provide a commit parameter, which gives us the immediate rev hash. From here, the regular commit parsing should take place to build the changelog.

I think this behavior is fixed after you merge your branch to main/master on github

I did not see any code in the semantic_release.cli.changelog() process flow that would suggest that the generation of the changelog checks which branch it is on or the use of config.get('branch') configuration variable. If I missed something then please let me know.

@relekang / other maintainers, please let me know which method (1, 2, or alternative) you prefer and I'll try to find some spare time to create a PR.

This bug report has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.

This bug report has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.

This issue is stale because it has not been confirmed or planned by the maintainers and has been open 90 days with no recent activity. It will be closed in 7 days, if no further activity occurs. Thank you for your contributions.

Resolved by #362, and also obsolete as of v8 since version_source is no longer a configuration option