Flow
How the wrong version got past the checks
From one version list to a broken file that the repo's own checks accept.
1One version list
Says which version each library should carry
2Find the version line
A pattern that also fits plugin lines in Maven files
3Rewrite every match
Plugin lines get the library version too
4Check again
Nothing left to change, so it passes
5Release check
Sees a version line and passes
6Maven build
The likely place it finally fails
The Java client's build file says two Maven plugins are on the SDK's alpha version. As far as I know, those plugin versions don't exist. And the version check I wrote says the file is fine.
This came from one commit. It tried to keep my auth service's client libraries in step, close to ten languages of them. One file holds the version each library should have. A script checks each library against it, or rewrites it. Owner files, a release check per language, CI per language, and sample test responses came along too. Most of it is solid. The Java part isn't.
How the script finds the version
For each language, the script knows which file holds the version and what that line looks like. In check mode it does the rewrite in memory and fails if anything would change. In write mode it saves the rewrite.
One good choice: if the script finds no matching line, it fails. So a renamed field turns the check red. It doesn't just stop checking.
Finding too many is the hole
The script only asks "did I find zero?". It never asks "did I find more than one?". In a Maven file, the project's version line looks just like a plugin's version line. So the Java pattern hits all of them, and the rewrite changes all of them.
The committed file shows it. The two plugin lines hold the SDK version, and they sit at the script's shallow indent, not where they belong. I think write mode ran on the file once. I can't say who ran it.
Why the checks still pass
Once every version line says the SDK version, the rewrite changes nothing. So check mode passes. The release check only asks if a version line exists, and it finds one. Both checks are happy with the worst file in the set. The other languages got lucky, mostly by having only one line that matches.
Maven should still catch it, since the build needs that plugin. I haven't looked at the run, so that's a guess.
Watch the triggers, too. Each workflow runs only when its own language folder or its own workflow file changes. Fixing the shared script alone won't run the Java checks at all.
The owner files can't drift, and the live test can't fake a pass
Owner files are built from one record and compared on every run. Clients test against sample responses. The live test fails when its secrets are missing. It doesn't skip and show green.
The narrower rule
The rule I want is "exactly one match":
if len(found) != 1:
raise SyncError("want exactly one version line")
For Maven, I'd parse the XML and change only the project's own version. The two plugin lines I'll fix by hand.