Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Commit and tag messages use wrong serialization #14

Closed
skipperTux opened this issue May 5, 2023 · 7 comments · Fixed by #42
Closed

Commit and tag messages use wrong serialization #14

skipperTux opened this issue May 5, 2023 · 7 comments · Fixed by #42
Labels
bug Something isn't working
Milestone

Comments

@skipperTux
Copy link

skipperTux commented May 5, 2023

(Thanks for your effort of keeping this project alive 👍!)

  • bump-my-version version: version 0.4.0
  • Python version: 3.11.3
  • Operating System: Windows 11

Description

Using old "c4urself / bump2version" Ini-configuration does not work out of the box, also converting to .toml has the same issues. It seems like the default templates are overwritten by local templates in the files section.

What I Did

Running bumpversion --dry-run --verbose patch with the below configuration gives the following error.

 Did not find '1;3.1.0-rc+build.1031' in file: 'Import\Version.csv'

When removing the last file section it works, however the commit message is
Would commit to Git with message 'Bump version: 3.1.1031.0 -> 3.1.1031.1', but it should be
Would commit to Git with message 'Bump version: 3.1.0-rc+build.1031 -> 3.1.1-beta+build.1031', as this is from the default templates. The commit message uses the templates from the last files section "{major}.{minor}.{build}.{patch}", see below in configuration.

[tool.bumpversion]
current_version = "3.1.0-rc+build.1031"
parse = "(?P<major>\\d+)\\.(?P<minor>\\d+)\\.(?P<patch>\\d+)(-(?P<release>[0-9A-Za-z]+))?(\\+build\\.(?P<build>.[0-9A-Za-z]+))?"
serialize = [
	"{major}.{minor}.{patch}-{release}+build.{build}",
	"{major}.{minor}.{patch}+build.{build}"
]
commit = true
message = "Bump version: {current_version} -> {new_version}"
tag = false
tag_name = "{new_version}"
tag_message = "Version {new_version}"
allow_dirty = true

[tool.bumpversion.parts.release]
values = [
	"beta",
	"rc",
	"final"
]
optional_value = "final"

[tool.bumpversion.parts.build]
first_value = 1000
independent = true

[[tool.bumpversion.files]]
filename = "Properties\\AssemblyInfo.cs"
search = "[assembly: AssemblyFileVersion(\"{current_version}\")]"
replace = "[assembly: AssemblyFileVersion(\"{new_version}\")]"

[[tool.bumpversion.files]]
filename = "Properties\\AssemblyInfo.cs"
parse = "(?P<major>\\d+)\\.(?P<minor>\\d+)\\.(?P<build>\\d+)\\.(?P<patch>\\d+)"
serialize = [
	"{major}.{minor}.{build}.{patch}"
]
search = "[assembly: AssemblyVersion(\"{current_version}\")]"
replace = "[assembly: AssemblyVersion(\"{new_version}\")]"

[[tool.bumpversion.files]]
filename = "Import\\Version.csv"
parse = "(?P<major>\\d+);(?P<minor>\\d+);(?P<patch>\\d+);(?P<release>[0-9A-Za-z]+)?;(build\\.(?P<build>.[0-9A-Za-z]+))?"
serialize = [
	"{major};{minor};{patch};{release};build.{build}",
	"{major};{minor};{patch};;build.{build}"
]
search = "1;{current_version}"
replace = "1;{new_version}"
coordt added a commit that referenced this issue Jun 9, 2023
@coordt
Copy link
Member

coordt commented Jun 9, 2023

@skipperTux I'm sorry it took me a month to notice your issue.

I think there are two issues here:

  1. `Did not find '1;3.1.0-rc+build.1031' in file: 'Import\Version.csv'
  2. Would commit to Git with message 'Bump version: 3.1.1031.0 -> 3.1.1031.1'

I created a test in an attempt to reproduce your first issue. (didn't mean to put it in the master branch, but oh, well. Fridays, amirite?).

Please check if my test represents your first issue. You might not know Python, but I hope the code is clear enough to get the gist.

If the Version.csv contains the string, it should work as you have it.

Once we have resolved this issue, we can move on to the next one.

@skipperTux
Copy link
Author

With regards to my first issue and your test: I do not know Python, however I can read more than write code. For me the code looks like you turned my config and my files into a test case. So yes, your test represent my first issue very specifically. However when I run the test the test_issue_14 passes? I would have expected this test fails, or did you already fix the first issue?
Is the test maybe too specific, as the parse and serialize are confused IMHO?

$ pytest -r A tests/test_files.py --cov-report=term
============================================================================================================ test session starts =============================================================================================================
platform linux -- Python 3.11.3, pytest-7.3.2, pluggy-1.0.0
rootdir: /home/christoph/Projects/python/bump-my-version
configfile: pyproject.toml
plugins: mock-3.10.0, cov-4.1.0
collected 9 items                                                                                                                                                                                                                            

tests/test_files.py .........                                                                                                                                                                                                          [100%]

=================================================================================================================== PASSES ===================================================================================================================
_______________________________________________________________________________________________________________ test_issue_14 ________________________________________________________________________________________________________________
------------------------------------------------------------------------------------------------------------- Captured log call --------------------------------------------------------------------------------------------------------------
WARNING  bumpversion.config:config.py:179 Specified version (3.1.0-rc+build.1031) does not match last tagged version (0.5.0)

[snip]

========================================================================================================== short test summary info ===========================================================================================================
PASSED tests/test_files.py::test_get_glob_files[simple-glob]
PASSED tests/test_files.py::test_get_glob_files[recursive-glob]
PASSED tests/test_files.py::test_single_file_processed_twice
PASSED tests/test_files.py::test_multi_file_configuration
PASSED tests/test_files.py::test_issue_14
PASSED tests/test_files.py::test_search_replace_to_avoid_updating_unconcerned_lines
PASSED tests/test_files.py::test_non_matching_search_does_not_modify_file
PASSED tests/test_files.py::test_simple_replacement_in_utf8_file
PASSED tests/test_files.py::test_multi_line_search_is_found
============================================================================================================= 9 passed in 0.23s ==============================================================================================================

@coordt
Copy link
Member

coordt commented Jun 14, 2023

I went back and figure out what is going on.

  1. The error being reported needs to be corrected. It displays the default serialization of the version in the message instead of the actual version it is looking for.
  2. The real issue is that it can't find the serialized version in your Version.csv file. I reproduced it by replacing one of the semicolons with a dash in the Version.csv file.

So you need to check your Version.csv file to see if it contains the right information.

I created issue #20 to track that issue.

Can you verify that was the issue for the first problem before we dig into the second?

@skipperTux
Copy link
Author

With regards to my Git history, the Version.csv had the following content when I posted the issue

Id;Major;Minor;Patch;Release;Metadata
1;3;1;0;rc;build.1031

I may re-test this later, if needed, I still have the .bumpversion.toml etc. in a branch.

@skipperTux
Copy link
Author

Hi. I tested my old branch and .toml.config using the latest 0.5.1 version. The first issue "Did not find {version} in {file}" is gone/fixed 👍.
The commit and tag messages are IMHO still using the wrong serialized version, that is, the version from the last file config. I would expect the default serialized version is used for commit and tag messages, as those are defined in the same (= default) config section.
Using the above .toml-config here are more details showing the logs.

PS> bumpversion --dry-run --tag --verbose patch
Starting BumpVersion 0.5.1
Reading config file .bumpversion.toml:
Parsing version '3.1.0-rc+build.1031' using regexp
'(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(-(?P<release>[0-9A-Za-z]+))?(\+build\.(?P<build>.[0-9A-Za-z]+))?'
Parsed the following values: build=1031, major=3, minor=1, patch=0, release=rc
Attempting to increment part 'patch'
Values are now: build=1031, major=3, minor=1, patch=1, release=beta
New version will be '3.1.1-beta+build.1031'
Dry run active, won't touch any files.
Asserting files acme.Setup\SqlScripts\Import\Version.csv, acme.App\Properties\AssemblyInfo.cs
contain the version string...
Found '[assembly: AssemblyFileVersion("3.1.0-rc+build.1031")]' in acme.App\Properties\AssemblyInfo.cs at line
40: [assembly: AssemblyFileVersion("3.1.0-rc+build.1031")]
Found '[assembly: AssemblyVersion("3.1.1031.0")]' in acme.App\Properties\AssemblyInfo.cs at line 39:
[assembly: AssemblyVersion("3.1.1031.0")]
Found '1;3;1;0;rc;build.1031' in acme.Setup\SqlScripts\Import\Version.csv at line 1: 1;3;1;0;rc;build.1031

[snip]

Would change file acme.Setup\SqlScripts\Import\Version.csv:
*** before acme.Setup\SqlScripts\Import\Version.csv
--- after acme.Setup\SqlScripts\Import\Version.csv
***************
*** 1,2 ****
  Id;Major;Minor;Patch;Release;Metadata
! 1;3;1;0;rc;build.1031
--- 1,2 ----
  Id;Major;Minor;Patch;Release;Metadata
! 1;3;1;1;beta;build.1031
Could not find the current version in the config file: .bumpversion.toml.

I assume the version cannot be found in the config, because the serialized version for the CSV is now used. However the config version already has been successfully found and parsed, see begin of the log.

Would prepare Git commit
Would add changes in file '.bumpversion.toml' to Git
Would add changes in file 'acme.Setup\SqlScripts\Import\Version.csv' to Git
Would add changes in file 'acme.App\Properties\AssemblyInfo.cs' to Git
Would commit to Git with message 'Bump version: 3;1;0;rc;build.1031 -> 3;1;1;beta;build.1031'
Would tag '3;1;1;beta;build.1031' with message 'Version 3;1;1;beta;build.1031' in Git and not signing

The commit and tag messages are using the serialized version from the CSV, not the one defined in the default section of the config, that is 3.1.0-rc+build.1031 -> 3.1.1-beta+build.1031. Again, in the begin of the log it can be seen that those versions already have been parsed successfully.

@coordt coordt changed the title Default templates overwritten by file-local templates? Commit and tag messages use wrong serialization Jul 3, 2023
@coordt coordt added the bug Something isn't working label Jul 3, 2023
@coordt coordt added this to the 1.0 Release milestone Jul 12, 2023
@skipperTux
Copy link
Author

Looking forward to see this in the 1.0 Release. Anything I can do to support you with this issue (e.g. testing, example repo)?

@coordt
Copy link
Member

coordt commented Aug 5, 2023

I'll work on this next week. I need to write a failing test to isolate the issue.

coordt added a commit that referenced this issue Aug 7, 2023
- Resets the context before committing and tagging
- Fixes #14
@coordt coordt linked a pull request Aug 7, 2023 that will close this issue
@coordt coordt closed this as completed in #42 Aug 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants