feat(test/tw): add version-pin-drift pipeline

[Aditevil]

What

Adds test/tw/version-pin-drift, a reusable test pipeline that flags drift between a runtime version pinned in a melange package and the version the upstream project declares it targets.

It fetches the upstream version config from the project's repo (at the package version, trying X.Y.Z and vX.Y.Z; overridable) and validates the pin per ecosystem:

ecosystem	source (comparison)
python	.python-version (==); requires-python / python_requires (in range)
nodejs	.nvmrc, .node-version (==); package.json engines.node (in range)
go	go.mod go directive (pin ≥, it's a minimum)
dotnet	global.json sdk.version (pin ≥)
ruby	.ruby-version, .tool-versions (==); Gemfile ruby (in range)

Comparison granularity follows the pin (3.11 → major.minor, 18 → major). Fails on a mismatch, an out-of-range pin, or when no upstream evidence is found.

Usage

Only ecosystem, repository, and pin are required; ref defaults to the package version.

- uses: test/tw/version-pin-drift
  with:
    ecosystem: python
    repository: https://github.com/mlrun/mlrun
    pin: ${{vars.python-version}}

Testing

tests/suites/version-pin-drift.yaml covers pass and fail cases per ecosystem against pinned upstream refs (mlrun, fastapi, next.js, cosign, mastodon). The extraction/comparison logic was validated directly against those repos, including exact-mismatch, out-of-range, go-below-minimum, and the ref fallback.

Notes

• repository and pin can't be auto-derived: melange doesn't expose the git-checkout URL or the consumer's vars to a uses: pipeline, and the package name doesn't map to the repo path.
• Java is intentionally omitted — the 1.8 == Java 8 duality (and gradle's many forms) can't be parsed reliably in shell, and a misleading check is worse than none.

🤖 Generated with Claude Code

[smoser]

One of the goals of tw is to get rid of yaml-bash.
I think its a win to replace that with a reasonably clear program call in yaml to a package-supplied bash script.
(As example, see 'ldd-check'... basically i'm asking you take this out of yaml and put it into a shell script that takes parameters).

Alternatively, you can put it in a go program that accepts parameters, which makes unit tests much easier to write.

[Aditevil]

makes sense, I'll write a go program for this.

[smoser]

can you give an example use of this?
I feel like its probably useful, i'm just not understanding.

[Aditevil]

can you give an example use of this?
I feel like its probably useful, i'm just not understanding.

Heres an example of a drift check I wrote.
https://github.com/chainguard-dev/stereo/blob/395c5768f62074ac9cb3d692a9f9dfd56f2ce577/enterprise-packages/mlrun-api.yaml#L220
Basically having a check to make sure "if upstream decides to migrate python version(for example) we update our builds too."

[smoser]

can you give an example use of this?
I feel like its probably useful, i'm just not understanding.

Heres an example of a drift check I wrote. https://github.com/chainguard-dev/stereo/blob/395c5768f62074ac9cb3d692a9f9dfd56f2ce577/enterprise-packages/mlrun-api.yaml#L220 Basically having a check to make sure "if upstream decides to migrate python version(for example) we update our builds too."

thanks. that was useful.