update-project-versions and verify-no-snapshot-versions can drift with nothing testing the pair

[ryanjbaxter]

verify-no-snapshot-versions rejects versions in locations that update-project-versions never writes, so a release can fail its own gate on something the automation was supposed to have fixed. Nothing tests the two actions together, so the two sides can drift silently.

How it surfaced

spring-cloud-function-commercial 5.0.4 passed readiness on 2026-08-04. spring-cloud-function-commercial release/5.1.0-M1 failed on 2026-09-07 with 12 violations, all in spring-cloud-function-samples/**/build.gradle.

Running each historical verifier against the same unchanged file:

Verifier	Date	Violations
b950928	2026-06-25	1 — version = only
a760372	2026-08-08	3 — plus springBootVersion, springCloudFunctionVersion

a760372 broadened the verifier to nested locations, which for build.gradle swept in ext { xxxVersion = ... } blocks. updateBuildGradleContent only ever rewrote the single version = '...' line, so the two stopped agreeing. Both actions' test suites stayed green for a month, because neither exercises the other.

The build.gradle half is now fixed — the updater resolves {prefix}Version properties the way gradle.properties already did, and rewrites inline org.springframework.* dependency coordinates for artifacts the train releases.

Still open

Location	Verifier	Updater
settings.gradle, settings.gradle.kts	checks	never opens the file
pom inline <dependency> / <plugin> / <extension> <version>	checks	reads, never writes — it writes only the project version, the parent version and properties

Neither has bitten yet: Spring Cloud poms express dependency versions through properties, and versions in settings.gradle are unusual. Both are the same shape as the bug above, waiting on the right repository.

Why identical coverage is the wrong goal

The verifier must catch things the updater must never touch. A -SNAPSHOT on a third-party dependency has to fail the release, and rewriting it to a Spring Cloud version would be wrong — that is exactly what a760372 was added for. The invariant worth enforcing is narrower:

Every location the verifier rejects is either one the updater fixed, or one nothing could fix — and the second kind is visible before the release, not at the gate.

Suggested approach

1. A conformance test. One fixture per file type, with a version in every location the verifier knows about. Run updater, then verifier, assert zero violations. This is the test that did not exist on 2026-08-08: it would have failed the moment the verifier was broadened. Cheap, and needs no refactoring. The fixture doubles as a readable specification of every place a version is managed.
2. Have the updater report what it skipped. When it meets a version-shaped value it cannot map to a project, log it as unmanaged. Turns a surprise gate failure into a visible line at stamp time, and covers the genuinely unfixable third-party case too.
3. A shared location model, only if divergence continues. One module enumerating version locations per file type, with the verifier flagging them and the updater writing those that resolve to a project. Makes divergence structurally impossible rather than merely tested against, at the cost of refactoring two actions that carry ~200 tests between them.

Recommend 1 and 2; keep 3 in reserve.

References

• Failing run: https://github.com/spring-cloud/spring-cloud-github-actions/actions/runs/34133819801
• a760372 — the verifier broadening
• .github/actions/verify-no-snapshot-versions/src/index.js
• .github/actions/update-project-versions/src/index.js