Version Not Bumped If Regex Right of Version

[Kurt-von-Laven]

Description

I attempted to use Commitizen to automatically increment a version number in .pre-commit-config.yaml.

pyproject.toml:

...
[tool.commitizen]
version = "0.0.0"
version_files = [
    ".pre-commit-config.yaml:Commitizen",
    "pyproject.toml:version"
]
...

.pre-commit-config.yaml:

...
- repo: ./
  rev: 0.0.0 # automatically updated by Commitizen
  hooks:
    - id: my-custom-hook
...

Steps to reproduce

1. Run cz bump.

Current behavior

The version numbers in pyproject.toml are incremented, but not the version number in .pre-commit-config.yaml. My understanding of the pertinent source code is that it only looks for the version number to the right of the regex.

Desired behavior

The version number in .pre-commit-config.yaml is incremented just like the version numbers in pyproject.toml. It may be simpler to process the file line by line. Some may be tempted to match on rev rather than a string in the comment, such as Commitizen, but that would cause Commitizen to bump every repo's rev that ever happens to be at the same version to the repository itself. YAML relies on vertical alignment, so I'm not aware of a way I can put a comment before the version number in my scenario.

Workarounds

Since the current processing is not line-by-line, in my particular scenario, I can specify a regex that matches part of the preceding line and part of the line containing the version number (e.g., repo.*\\./\\n\\s+rev). Personally, I don't feel that it is important to retain such undocumented functionality. Matching across lines in this manner seems likely to result in cryptic and brittle regexes (e.g., suppose a comment is added between the two lines) particularly since backslashes need to be escaped in TOML. A better approach, in my opinion, is to leverage lookahead assertions (e.g., rev.\\s+(?=[^\\n]+Commitizen)) to stop consuming the string before reaching the version number, but this still implies some unnecessary complexity and is prone to the pitfall of the developer assuming the matching is performed line-by-line. For instance, rev.\\s+(?=.+Commitizen) would match the first line matching rev.\\s+ provided "Commitizen" appears anywhere subsequently in the file. One of our open-source repositories demonstrates the lookahead assertion technique in case it's helpful to look around.

Screenshots

No response

Environment

Commitizen Version: 2.23.0
Python Version: 3.10.4 (main, Apr 5 2022, 17:28:03) [GCC 11.2.0]
Operating System: Linux

[lovetheguitar]

Just wanted to mention this plugin https://github.com/google/semantic-release-replace-plugin. Maybe commitizen could incorporate some of the behavior and features from there.

[Lee-W]

Hi @Kurt-von-Laven , thanks for reporting this issue! I've confirmed this behavior. Do you have any thing in mind that could solve this one?