feat(checks): oci-incompatible-version, for a version that cannot be an OCI tag #23

Merged

mikluko merged 2 commits from mikluko/octant/1724-semver-compliance into main

2026-09-06 20:23:54 +00:00

mikluko commented

2026-09-06 20:22:18 +00:00

(Migrated from github.com)

Octant: T1725. This is #22's content, which did not reach main.

#22 was stacked on mikluko/octant/1724-semver-compliance and merged into that branch rather than into main — the same way #17 merged into #14's branch earlier. #21 had already landed the compliance section, so the branch was left 2 commits ahead of main carrying oci-incompatible-version and nobody tracking it. main currently has 17 checks; this makes it 18.

The change itself is unchanged from #22, which was reviewed and green. Repeating the substance:

Build metadata is valid Semantic Versioning and cannot be an OCI tag. The specification permits 1.2.3+build.1; the OCI tag grammar is [a-zA-Z0-9_][a-zA-Z0-9._-]{0,127}, which has no +. Git ref syntax does permit it, so such a version cuts a tag and is then not a name a registry takes.

parser        is this a version?               the specification decides
this check    can this version be an OCI tag?  the OCI grammar decides

It implements the grammar rather than the one case, so the 128-character bound is checked too — a pre-release run has no bound in SemVer. The finding names the character or the length at fault.

The first check whose subject is outside the document, and the register's description says so. A repository that publishes no image or chart switches it off in off:, and there is a test pinning that escape hatch because the error default leans on it.

Default confirmed as error by the human, which is what the ticket asked for rather than defaulted to.

Octant: [T1725](http://127.0.0.1:9876/T1725). **This is #22's content, which did not reach `main`.** #22 was stacked on `mikluko/octant/1724-semver-compliance` and merged into that branch rather than into `main` — the same way #17 merged into #14's branch earlier. #21 had already landed the compliance section, so the branch was left 2 commits ahead of `main` carrying `oci-incompatible-version` and nobody tracking it. `main` currently has 17 checks; this makes it 18. The change itself is unchanged from #22, which was reviewed and green. Repeating the substance: Build metadata is valid Semantic Versioning and cannot be an OCI tag. The specification permits `1.2.3+build.1`; the OCI tag grammar is `[a-zA-Z0-9_][a-zA-Z0-9._-]{0,127}`, which has no `+`. Git ref syntax *does* permit it, so such a version cuts a tag and is then not a name a registry takes. ``` parser is this a version? the specification decides this check can this version be an OCI tag? the OCI grammar decides ``` It implements the grammar rather than the one case, so the 128-character bound is checked too — a pre-release run has no bound in SemVer. The finding names the character or the length at fault. **The first check whose subject is outside the document**, and the register's description says so. A repository that publishes no image or chart switches it off in `off:`, and there is a test pinning that escape hatch because the `error` default leans on it. Default confirmed as `error` by the human, which is what the ticket asked for rather than defaulted to.