Bug Report
Separated into its own issue from #1125, comments from @JonZeolla
Description
In order to resolve #1125, I implemented your two step workflow documented in #1125 (comment). And unfortunately it seems with v9.20.0, the 2 step workflow does not commit the version_variables and version_toml changes unless I intentionally stage them myself.
Expected behavior
The version_variables and version_toml configured files are committed with the release commit while also allowing me to keep uv.lock updated in between the steps.
Actual behavior
The version files were not committed in the release commit while the uv.lock was. The version files remained in the working directory
Environment
- Operating System (w/ version):
- Python version:
- Semantic-release version: v9.20.0
Configuration
Semantic Release Configuration
[tool.semantic_release]
major_on_zero = false
version_toml = [
"pyproject.toml:project.version",
]
version_variables = [
"src/example/__init__.py:__version__",
]
changelog_file = "CHANGELOG.md"
commit_parser = "angular"
commit_author = "Example <Example@example.com>"
commit_message = "chore(release): example {version}"
tag_format = "example=={version}"
[tool.semantic_release.branches.release]
match = "main"
[tool.semantic_release.publish]
dist_glob_patterns = ["path_relative_to_root/example/dist/*"]
upload_to_vcs_release = true
[tool.semantic_release.remote]
name = "origin"
type = "github"
ignore_token_for_push = false
insecure = false
Execution Log
semantic-release -vv version
Additional context
My guess is that it's this and this. Since we stage the changes before running the --commit, the new_content is the same as self.content (in the working tree), so it returns None.
Then, that doesn't add the file path to paths here, which means it is not added to files_with_new_version_written here:
|
files_with_new_version_written = apply_version_to_source_files( |
|
repo_dir=runtime.repo_dir, |
|
version_declarations=runtime.version_declarations, |
|
version=new_version, |
|
noop=opts.noop, |
|
) |
|
all_paths_to_add.extend(files_with_new_version_written) |
And then finally, it isn't staged and commit here:
|
if commit_changes: |
|
project.git_add(paths=all_paths_to_add, noop=opts.noop) |
|
|
|
# NOTE: If we haven't modified any source code then we skip trying to make a commit |
|
# and any tag that we apply will be to the HEAD commit (made outside of |
|
# running PSR |
|
try: |
|
project.git_commit( |
|
message=commit_message.format(version=new_version), |
|
date=int(commit_date.timestamp()), |
|
no_verify=no_verify, |
|
noop=opts.noop, |
|
) |
|
except GitCommitEmptyIndexError: |
|
log.info("No local changes to add to any commit, skipping") |
Bug Report
Separated into its own issue from #1125, comments from @JonZeolla
Description
In order to resolve #1125, I implemented your two step workflow documented in #1125 (comment). And unfortunately it seems with v9.20.0, the 2 step workflow does not commit the
version_variablesandversion_tomlchanges unless I intentionally stage them myself.Expected behavior
The
version_variablesandversion_tomlconfigured files are committed with the release commit while also allowing me to keep uv.lock updated in between the steps.Actual behavior
The version files were not committed in the release commit while the
uv.lockwas. The version files remained in the working directoryEnvironment
Configuration
Semantic Release Configuration
Execution Log
semantic-release -vv versionAdditional context
My guess is that it's this and this. Since we stage the changes before running the
--commit, thenew_contentis the same asself.content(in the working tree), so it returnsNone.Then, that doesn't add the file path to
pathshere, which means it is not added tofiles_with_new_version_writtenhere:python-semantic-release/src/semantic_release/cli/commands/version.py
Lines 617 to 623 in 5093f30
And then finally, it isn't staged and commit here:
python-semantic-release/src/semantic_release/cli/commands/version.py
Lines 654 to 668 in 5093f30