Repository navigation
feat(omni): single source of truth for versions + CI drift gate - #27
Merged
Merged
Conversation
…ine class Desired Talos/Kubernetes versions get one hand-owned home. talos-image.yaml stays the machine-written build ledger — it is rewritten wholesale by the talos-images workflow and records what was built, not what should run. unraid-control-plane.yaml was a hand-written duplicate of what omni-on-unraid's renderer generates for unraid-cp, and had already drifted: memory 4096 against the renderer's 6144, and no installImage at all. Refs: openspec/changes/automate-talos-upgrade-pipeline (tasks 1.4, 2.1)
… workflow The pluto job read kubernetes_version from omni/talos-image.yaml, which is the build ledger — it records what was last built, not what clusters run. With the ledger at v1.37.0-beta.0 and clusters on v1.36.3, the deprecation gate was checking the wrong target entirely. It now reads the desired pin from omni/versions.yaml and fails if that pin is missing. talos-image-update.yml was a second, competing PR-opening path: a repository_dispatch receiver that sed-bumps talos_version in the ledger and opens its own PR on a different branch from the one talos-images/build.yml opens. No sender exists in any repo (grepped all of ~/syscode/git), so it is orphaned — but if it ever fired it would bump talos_version without schematic_id or oci_image_ocid, producing a ledger pointing at a version whose image was never built. That is root cause #4 of the 2026-08-03 incident. Refs: openspec/changes/automate-talos-upgrade-pipeline
Nothing reconciled the derived files when versions.yaml changed without needing a new image — the build workflow only opens a PR when it has something to build, so flipping a cluster back to an already-built version left machine classes and templates stale with no failure anywhere. The checker caught live drift on its first run: both OCI machine classes still installed v1.14.0-beta.1 while oci-lab targets v1.13.7, so any node provisioned into oci-lab would have installed the beta. Repaired to v1.13.7. Kubernetes is never inherited across a diverging Talos target: a cluster that overrides talos without kubernetes is an error, not an inherit, because the global kubernetes pin belongs to a different Talos minor. Refs: openspec/changes/automate-talos-upgrade-pipeline
syscod3
added a commit
that referenced
this pull request
Aug 8, 2026
feat(omni): single source of truth for versions + CI drift gate
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Single hand-owned home for desired Talos/Kubernetes versions, plus a CI gate that makes drift unmergeable.
What
omni/versions.yaml— global pin + per-cluster overrides. Hand-owned.omni/talos-image.yamlstays the machine-written build ledger.scripts/check-version-drift.py— fails CI when any derived file disagreeswith the pin. Carries
--selftestfor the resolver logic..github/workflows/talos-image-update.yml— an orphaned second PRpath (no sender in any repo) that would bump
talos_versionwith noschematic_idoroci_image_ocid, i.e. a ledger pointing at an unbuiltimage. That is root cause chore: Talos upgrade to v1.12.7 #4 of the 2026-08-03 incident.
omni/machine-classes/unraid-control-plane.yaml— hand-writtenduplicate of the omni-on-unraid renderer output, already drifted
(
memory: 4096vs the renderer's6144, noinstallImage).build ledger. It was checking v1.37.0-beta.0 while clusters run v1.36.3.
Drift repaired
The new gate failed on its first run: both OCI machine classes installed
v1.14.0-beta.1while oci-lab targetsv1.13.7, so any node provisionedinto oci-lab would have installed the beta. Repaired to v1.13.7.
Merge this first — omni-on-unraid, talos-images and oci-free-tier-manager all
read
versions.yamlfrommain.Plan:
openspec/changes/automate-talos-upgrade-pipelinein syscode-ai-internal-plans.