René's URL Explorer Experiment

Title: fix(bump): flag sibling version mismatches under --check-consistency by bearomorphism · Pull Request #1978 · commitizen-tools/commitizen · GitHub

Open Graph Title: fix(bump): flag sibling version mismatches under --check-consistency by bearomorphism · Pull Request #1978 · commitizen-tools/commitizen

X Title: fix(bump): flag sibling version mismatches under --check-consistency by bearomorphism · Pull Request #1978 · commitizen-tools/commitizen

Description: Description Closes #595. Why commitizen/bump.py:update_version_in_files applies a regex pattern to each line of every file in version_files. When a broad pattern such as pyproject.toml:version is used, the regex legitimately matches multiple version = lines — one under [tool.commitizen] holding the current commitizen-managed version, and one under [tool.poetry] (or [project] for PEP-621) holding a potentially out-of-sync value maintained by a different tool. The old inner loop (master commitizen/bump.py:88-95) replaced the current_version string wherever pattern.search(line) was true and set current_version_found only when the replacement changed the line. The loop never inspected lines that matched the pattern but did not contain current_version, so the [tool.poetry].version line was silently skipped — the bump proceeded, --check-consistency raised no error, and the file was left with two different version strings. The original reporter @gpongelli observed the mismatch in commitizen 2.34.0; maintainer @Lee-W confirmed the reproduction and noted that the regex-based approach made a proper same-file consistency check architecturally difficult. A follow-up comment from @woile noted the workaround (use a more specific regex such as pyproject.toml:\[tool\.poetry\][.\s\D]*^version). The triage audit on #1964 confirmed the issue is still present in master (v4.15.1): a pyproject.toml with [tool.poetry].version = "2.5.7" and [tool.commitizen].version = "2.5.2" running cz bump --check-consistency --yes exits 0, bumps commitizen's version to 2.6.0, and leaves the poetry version at 2.5.7 — still mismatched and silent. This PR narrows the fix: when check_consistency=True, any line that (a) matches the version-files regex and (b) does not contain current_version but (c) contains a semver-shaped value is collected as an inconsistent_lines entry. If any such entries exist after processing the file, CurrentVersionNotFoundError is raised with a message that names the file path, the line number, and the offending version string so the user knows exactly which tool is out of sync. The default path (check_consistency=False) is completely unchanged. What changed File Change commitizen/bump.py Refactor inner loop (was lines 88–95) to enumerate lines and track inconsistent_lines; add _LIKELY_VERSION_VALUE_RE module-level constant; raise CurrentVersionNotFoundError with line-level details when check_consistency=True and sibling mismatches are found tests/test_bump_update_version_in_files.py Two new regression tests: sibling detection raises with both version strings in the error message; legacy no-check_consistency behaviour leaves sibling untouched without raising How it works Two-phase consistency check. The existing check (master commitizen/bump.py:98-103) validates that at least one line was updated — i.e., current_version was found. The new check is a second gate that validates that no other line looks like it stores a different version. Both checks run after the full file is read, before any write occurs, so a failed consistency check always leaves the file on disk untouched. _LIKELY_VERSION_VALUE_RE is intentionally conservative. The regex \d+\.\d+\.\d+(?:[\w.\-+]*) matches the canonical MAJOR.MINOR.PATCH semver shape (plus optional pre-release and build-metadata suffixes). It deliberately does not match bare integers, Python import paths, comment prose, or generic version = keywords without a version-shaped right-hand side. This prevents false positives from unrelated occurrences of the word version in configuration comments or code that the user's regex happens to match. Line numbers are 1-based in the error message. enumerate(version_file, 1) is used so that the reported line number matches what editors and grep -n report. This makes the error message actionable without requiring the user to open the file and count from zero. check_consistency=False path is byte-for-byte identical to the old behaviour. The inconsistent_lines list is only evaluated inside the if check_consistency block. No code runs on the fast path for users who do not pass --check-consistency. Why not a TOML-aware parser? @woile and @Lee-W discussed this in the issue thread: a format-specific parser (TOML, JSON, YAML) would add maintenance burden and break the general version_files: any-file contract. The regex approach is deliberately format-agnostic; the conservative _LIKELY_VERSION_VALUE_RE secondary filter is enough to catch the common pyproject.toml case without committing to TOML semantics. Backward compatibility check_consistency=False (the default) preserves the legacy behaviour exactly: only lines containing current_version are rewritten; sibling lines are left alone; no exception is raised. The new CurrentVersionNotFoundError message format is a superset of the existing one — both state the file path and the fact that the version wasn't found; the new message additionally names the offending line. All pre-existing update_version_in_files tests and bump command tests pass unchanged. No CLI flags or configuration keys are added; --check-consistency is the existing flag whose scope is extended. Checklist I have read the contributing guidelines Was generative AI tooling used to co-author this PR? Yes (please specify the tool below) Generated-by: Claude following the guidelines Code Changes Add test cases to all the changes you introduce Run uv run poe all locally to ensure this change passes linter check and tests Manually test the changes (see "Steps to Test" below) Update the documentation for the changes Expected Behavior Scenario Outcome pyproject.toml with [tool.poetry].version = "2.5.7" and [tool.commitizen].version = "2.5.2", version_files = ["pyproject.toml:version"], cz bump --check-consistency Exits non-zero; error message names line 2: version = "2.5.7" as the inconsistent entry; file is not modified Same setup, cz bump (no --check-consistency) Bumps only the commitizen version line; poetry line is left at 2.5.7; no exception — legacy behaviour preserved Single version = line in file, cz bump --check-consistency Works as before — inconsistent_lines is empty, no new error version_files regex narrowed to pyproject.toml:\[tool\.commitizen\] Poetry line never matches the regex; inconsistent_lines is empty regardless of --check-consistency Steps to Test This Pull Request git fetch fork fix/595-check-consistency-version-mismatch git checkout fork/fix/595-check-consistency-version-mismatch # 1. Targeted regression tests. uv run pytest \ tests/test_bump_update_version_in_files.py::test_update_version_in_files_check_consistency_detects_sibling_version \ tests/test_bump_update_version_in_files.py::test_update_version_in_files_check_consistency_off_keeps_legacy_behaviour \ -v # 2. Reproduce-the-bug-then-verify-the-fix sequence (exact scenario from #595). mkdir cz595 && cd cz595 git init -b main git config user.name test && git config user.email test@example.com cat > pyproject.toml << 'EOF' [tool.poetry] name = "cool_proj" version = "2.5.7" [tool.commitizen] name = "cz_conventional_commits" version = "2.5.2" version_files = ["pyproject.toml:version"] EOF git add pyproject.toml && git commit -m "feat: initial setup" # Before fix: exits 0, silently bumps commitizen version only, leaves poetry at 2.5.7. # After fix: exits non-zero, prints offending line (version = "2.5.7"), file untouched. cz bump --check-consistency --yes # Verify file was NOT modified on failure: grep 'version = "2.5.2"' pyproject.toml # must still be present # Verify legacy behaviour (no --check-consistency) is unchanged: cz bump --yes grep 'version = "2.6.0"' pyproject.toml # commitizen line bumped grep 'version = "2.5.7"' pyproject.toml # poetry line untouched — expected Additional Context This fix was scoped during the issue audit in #1964, which confirmed the silent-pass behaviour is still present in master (v4.15.1). The implementation deliberately stays within the existing regex-based version_files contract rather than introducing format-specific parsing, consistent with the design discussion in the #595 thread (@woile, @Lee-W). Users whose version_files regex is already specific enough to target only the commitizen-managed line are unaffected — their _LIKELY_VERSION_VALUE_RE scan will find no inconsistent lines.

Open Graph Description: Description Closes #595. Why commitizen/bump.py:update_version_in_files applies a regex pattern to each line of every file in version_files. When a broad pattern such as pyproject.toml:version is u...

X Description: Description Closes #595. Why commitizen/bump.py:update_version_in_files applies a regex pattern to each line of every file in version_files. When a broad pattern such as pyproject.toml:version is u...

Opengraph URL: https://github.com/commitizen-tools/commitizen/pull/1978

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width