Pin catalog components by major
Standard
pipeline
Change type
- Modify existing standard (prose only)
- Modify existing standard's check.sh (change an assertion)
- Modify existing standard's templates
What does this MR do and why?
Catalog component pins become the major, @6, instead of a full @vX.Y.Z
tag, so a patch to a component reaches its consumers without an edit in each
one. Minors and patches resolve to the newest matching catalog release at
pipeline time; a major bump stays the deliberate edit, read against the
catalog CHANGELOG's breaking section. The pipeline standard asks for the
major rather than tolerating it, and a full pin still passes for migration.
Carried with it, because the pins cannot land without them: CATALOG-VERSION
holds 6, just sync and just validate read and write @6 and match either
pin shape, and the paper template's @~latest becomes @6. reference_version
stays full semver, since the reference is not a catalog resource.
Failure mode this addresses
check.sh:16 asserted @v?[0-9]+\.[0-9]+\.[0-9]+, so @6 failed
just check-one STANDARD=pipeline while resolving correctly on the platform.
The same assertion accepted @6.2.2, and SKILL.md said "Both @v1.5.0 and
@1.5.0 are accepted". That form has never resolved: a partial is resolved as
a range over release versions, a three-part version as a literal tag, and this
catalog's tags are named vX.Y.Z. The standard was passing a pin whose
pipeline cannot start.
Assertion deltas
- MODIFY:
file-contains:.gitlab-ci.yml, from@v?[0-9]+\.[0-9]+\.[0-9]+to@(v[0-9]+\.[0-9]+\.[0-9]+|[0-9]+(\.[0-9]+)?)([^0-9.]|$)
The alternation is the resolver's own grammar, verified against the live catalog
with POST /projects/:id/ci/lint on pipeline/vale: @6, @6.2, @v6.2.2
and @~latest resolve, while @6.2.2, @v6 and @v6.2 return content not
found. The trailing boundary is load bearing, because grep -E matches a
substring and the partial branch otherwise matches the 6.2 in @6.2.2.
Consumer impact
A full @vX.Y.Z pin keeps passing, and @6 passes where it previously failed.
@6.2.2, @v6 and @v6.2 now fail, and those includes do not resolve today
either. Consumers move their own pins to @6 in a separate sweep.
Test plan
-
just guardpasses (assertions use only closed primitives) -
just check-one STANDARD=pipelinepasses against this repo - Four fixtures, two negative:
@6and@v6.2.2pass 5/0;@v6,@6.2.2fail 4/1 -
just validateandjust checkgreen, 21 standards pass and 0 fail - CHANGELOG updated