Add per-branch custom version pinning via config file

[Jardo-51]

Summary

Adds optional per-branch version pinning driven by a repo-committed config file (default .prevent-overwrites.conf). Branch patterns can pin the project version and/or specific dependency versions to explicit values; when no config file exists or no entry matches the current branch, behaviour is unchanged.

• Config format: line-based, whitespace-separated (branch-pattern target value), pure bash — no yq/external dependency, so it works identically on every runner including the GitLab Maven image.
• Restore: pinned values must follow the <base>-<suffix>-SNAPSHOT pattern, so the existing core-branch restore logic reverts them automatically on merge. Values that don't match hard-fail the job.
• Scope: project-version pins apply only when enforce-branch-version: true; dependency:<groupId>:<artifactId> pins apply on feature branches regardless (so application projects can pin what they build against).
• New config-file input for both the GitHub Action and the GitLab component.

Changes

• prevent-overwrites.sh — load_config_overrides(), pin-aware enforce_branch_version(), new apply_dependency_pins(), wired into main.
• action.yml / gitlab/prevent-overwrites.yml — new config-file input.
• README.md — new "Custom Per-Branch Version Pinning" section + input tables.

Testing

bash test/run-all-tests.sh — 10/10 pass (6 pre-existing + 4 new: project-version pin, dependency pins, no-match fallback, invalid-pin hard-fail).

🤖 Generated with Claude Code

[Jardo-51]

Code Review — PR #2: Per-branch custom version pinning

Reviewed the full diff against the feature/gitlab base. Ran bash test/run-all-tests.sh → 13/13 pass. Overall this is a clean, well-tested, well-documented addition that preserves the "no config → unchanged behaviour" contract. Comments below are suggestions/risks, none are hard blockers.

Overview

• Adds load_config_overrides() that parses an optional repo-committed config (.prevent-overwrites.conf) into project-version pins, dependency pins, and exclusive-suffix declarations.
• enforce_branch_version() reworked so an explicit pin (or an exclusive-suffix re-derive) wins over the "already has a branch version → leave alone" legacy path.
• New apply_dependency_pins() rewrites matching <dependency> versions via awk, independent of ENFORCE_BRANCH_VERSION.
• New config-file input wired through both action.yml and the GitLab component; README + CHANGELOG updated.

Strengths

• Test coverage is excellent — project-version pin, dependency pins, no-match fallback, invalid-pin hard-fail, inline/full-line comments, and both exclusive-suffix directions (owner unchanged + inherited re-derive).
• Pure-bash parser with no yq/external dependency keeps parity across runners — good call, matches the project's stated design constraint.
• Requiring pinned values to match <base>-<suffix>-SNAPSHOT so the existing core-branch restore reverts them automatically is a nice, consistent design.

Issues & suggestions

1. enforce_branch_version now commits unconditionally after the write loop — empty-commit risk under set -e. (prevent-overwrites.sh:288-305)
The git commit -a was moved out of the "default derive" branch and now runs for all non-early-return paths. If the write loop produces no actual change — e.g. a child module whose PROJECT_VERSION is inherited from <parent> (the awk skips the <parent> block, so nothing is rewritten) — git commit -a finds nothing staged, exits non-zero, and set -e kills the whole job. The derive path had this shape before, but pinning a project-version on a parent-inheriting module is a new way to reach it. Consider guarding the commit on an actual-change check (as apply_dependency_pins already does with cmp).

2. Multiple matching project-version pins are silently dropped. (prevent-overwrites.sh:194-197)
First match in file wins (if [[ -z "$PINNED_PROJECT_VERSION" ]]). If both feature/* and feature/f1 match the current branch, the second is ignored with no warning. A log_info/log_error on a second match would save a confusing debugging session.

3. apply_dependency_pins awk matches any <dependency> block. (prevent-overwrites.sh:332-360)
It will also rewrite dependencies under <dependencyManagement> and <build><plugins><plugin><dependencies>. Also, a dependency using <version>${some.property}</version> would have the property reference replaced with a literal. Probably fine for the intended use, but worth a note in the README's Rules section so users aren't surprised.

4. Pinned-value regex is broad enough to break the later sed restore. (prevent-overwrites.sh:135)
^[0-9]+\.[0-9]+\.[0-9].*-.+-SNAPSHOT$ accepts characters like |, &, / in the .*/.+ sections. Such a value passes validation but would later break sed -i "s|${version}|..." in remove_dependency_branch_versions on the core-branch merge. Tightening the suffix character class (e.g. [A-Za-z0-9._-]+) would make the round-trip safe.

5. Minor: indentation leftover from the refactor. (prevent-overwrites.sh:288-305)
The while … done, git commit, and ENFORCE_CHANGES_MADE="true" are over-indented relative to the enclosing function (a remnant of lifting the block out of the old else). Harmless but worth a cleanup pass for readability.

Correctness / conventions / security

• Empty-array handling (${#ARR[@]} guards) and the # shellcheck disable=SC2053 glob-match annotations follow the existing check_branch_needs_version convention — good.
• Config is repo-owned (same trust level as pom.xml), so glob/awk value injection is low-risk; item 4 is the main robustness edge.
• git commit -a won't pick up the untracked .prevent-overwrites.conf in tests, and commits it in real repos where it's tracked — correct either way.

Nice work overall — addressing #1 (empty-commit guard) is the one I'd most encourage before merge.

Reviewed by Claude Code