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

Use of version_provider doesn't add changed files on cz bump #1108

Closed
kassi opened this issue May 14, 2024 · 2 comments
Closed

Use of version_provider doesn't add changed files on cz bump #1108

kassi opened this issue May 14, 2024 · 2 comments

Comments

@kassi
Copy link

kassi commented May 14, 2024

Description

When using a custom version provider that changes some arbitrary file defined in the version provider itself, this file is not added to git on a cz bump.
Only files defined within version_files are added. However having to specify the file that is being changed within the version provider also inside version_files may lead to problems.

Steps to reproduce

  • Specify a version provider, e.g. commitizen_lrplugin or commitizen_ruby (without specifying the actual version file in version_files
  • bump the version with cz bump
  • run git status
  • see that the version file has not been committed.

Current behavior

The file with version number changed by the version provider is not added to the bump commit.

Desired behavior

The file with version number changed by the version provider should be automatically added to the bump commit.

Screenshots

No response

Environment

Commitizen Version: 3.25.0
Python Version: 3.12.3 (main, Apr 16 2024, 11:43:44) [Clang 15.0.0 (clang-1500.1.0.2.5)]
Operating System: Darwin

@woile
Copy link
Member

woile commented May 15, 2024

Is the file being tracked by git? commitizen does git commit -a which should include modified files during bump

@kassi
Copy link
Author

kassi commented May 17, 2024

@woile yes, it's tracked by git. I tested again and again and finally realized, that the file is being checked-in, but after the commit increasing the version number, some automatism updated itself in the lock file (Gemfile.lock in this case), raising the version number and making the repo dirty again. I'll close this issue and have to figure out what's causing this in the ruby environment.

@kassi kassi closed this as completed May 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants