python-semantic-release
change log list is empty, Not created any chagelog.md file on existing repo
I have existing project, now i want to semantic-release to create change log so i have installed python-semantic-release and set below configuration
setup.cfg
[semantic_release] version_variable = init.py:version branch = "feature/test-sm" ;commit_version_number = true ;version_source = tag
version = "1.0.0"
and ran
semantic-release changelog -v DEBUG
and the results are
debug: get_last_version(['1.0.0', 'v1.0.0']) debug: generate_changelog(None, '1.0.0') debug: generate_changelog -> {'breaking': []} debug: get_repository_owner_and_name() debug: get_repository_owner_and_name -> ('deepthinkers', 'td-solutions') debug: markdown_changelog('deepthinkers', 'td-solutions', '1.0.0', {'breaking': []}, header=False) debug: markdown_changelog ->
ideally it should create some changelog md file i am not wrong
BTW , I have few commits on this configure branch
Author: Tiru Date: Mon Aug 2 12:27:47 2021 +0530
"feat: add semantic release "
commit 5d7b953d148ab8832c5002a504627a37d4c4c955 Author: Tiru Date: Mon Aug 2 12:26:51 2021 +0530
"BREAKING: add semantic release "
commit 009779944d9c4ecb066995ee96597a0d91edb440 Author: Tiru Date: Mon Aug 2 12:26:08 2021 +0530
"BREAKING CHANGE: add semantic release "
those commit are proceed when i run change long command
debug: get_current_version_by_config_file() debug: Parsing current version: path=PosixPath('init.py') pattern='version *[:=] *"\'["\']' num_matches=1 debug: Regex matched version: 1.0.0 debug: get_current_version_by_config_file -> 1.0.0 debug: get_previous_version('1.0.0') debug: Checking commit 498d7c201d6aa19f8c7464757e0d4f8eb2188ec5 debug: Checking commit 5d7b953d148ab8832c5002a504627a37d4c4c955 debug: Checking commit 009779944d9c4ecb066995ee96597a0d91edb440 debug: Checking commit 926aaf1eb6cce549b146f09d1c330d3a16809af2
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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 <[email protected]>
Date: Mon Apr 4 10:02:22 2022 +0200
feat(logging): added logs for failed signups
commit dfeed23de3b7618bcc5282ac2661521ed98af5bf
Author: Martin Neubert <[email protected]>
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