feat(meta): agent-platform-connectivity follows the meta chart's own version; verify-components-charts renders the whole roster and holds the BOM to it - #450
Conversation
Published Helm chart
|
| Chart | agent-platform |
| Version | 4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8 |
| OCI reference | oci://gsoci.azurecr.io/charts/giantswarm/agent-platform:4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8 |
| Digest | sha256:33553d590500bfbc8979799391d70e4936bc873b88eae875dac63bf43db44a32 |
| Registry | public — gsoci.azurecr.io |
| Git catalog | giantswarm-test-catalog (index) |
Pull this chart
helm pull oci://gsoci.azurecr.io/charts/giantswarm/agent-platform --version 4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8Posted by architect-orb · build 8020 · commit 28d2ce8 · updated in place on every push
Published Helm chart
|
| Chart | agent-platform-connectivity |
| Version | 4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8 |
| OCI reference | oci://gsoci.azurecr.io/charts/giantswarm/agent-platform-connectivity:4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8 |
| Digest | sha256:7a9867f95f55923e72a45f3bbeb35a4d36f7c1953156a0e5ddd7c8f070a0dccb |
| Registry | public — gsoci.azurecr.io |
| Git catalog | giantswarm-test-catalog (index) |
Pull this chart
helm pull oci://gsoci.azurecr.io/charts/giantswarm/agent-platform-connectivity --version 4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8Posted by architect-orb · build 8021 · commit 28d2ce8 · updated in place on every push
d6a3caa to
513f432
Compare
|
Rebased onto main (10 commits). The #339 fixed a false positive in that script while this PR was open, and this PR needed it more than the original did. That rule is carried over, and connectivity's two axes collapse into one working-tree render: It is load-bearing today, not a precaution. With Those are #339's own keys, added to both charts in one commit. Without the carry-over this PR would have broken Everything else survived: 22 components, both axes, and main's re-pins are picked up with no change to the script (Substrate
|
…ins, not a list kept by hand The check rendered thirteen components named in the script itself, so agent-platform-connectivity, klaus-gateway, muster, agentgateway, valkey, agent-platform-mcps, agent-sandbox, dicebear and vm-manager were never rendered against the values the meta chart forwards to them. That list is what let #278's three breaks reach main: gateway.parameters.podAnnotations (#431) -> connectivity, not on the list vm-manager / vmManager (#441) -> connectivity, not on the list podDisruptionBudget / podAnnotations -> klaus-gateway, not on the list Each of those charts validates with additionalProperties: false, so every BOM-pinned installation got a release that could not install or upgrade, and the check that exists to catch exactly this could not see them. The set now comes from the BOM -- the roster of what an installation actually gets -- so a component is covered the day it is pinned rather than the day someone remembers to add it, and a pin the meta chart renders no OCIRepository for fails rather than skipping quietly. 22 components, at the range's resolution and at the BOM pin. LOCAL_CHARTS comes over from verify-bom-charts.py with it (#339): agent-platform-connectivity ships from this repo off the same tag as the meta chart, so the pair an installation gets is always the pair in this commit. It is rendered from the working tree and its two axes collapse to that one render. This is load-bearing today, not a precaution -- with the rule removed the check fails on postgres.affinity and postgres.imagePullSecrets, keys #339 added to both charts in one commit, which no published connectivity carries yet. tests/verify-bom-charts.py and its verify-meta step go. This check does strictly more: it renders the charts through, where that one only proved the schema accepted the values, and it covers the resolved range as well as the pin. Proven by putting either pin back: 4.8.0 fails naming podAnnotations and vmManager, 1.0.2 fails naming podDisruptionBudget and podAnnotations. The inputs an installation supplies and the meta chart leaves empty (the resource servers' OAuth clients, a public Gateway for the routes, valkey's ACL secret) are ALL_ON_INPUTS, kept apart from QUICKSTART on purpose: verify-kagent-tools-namespace.py, verify-kyverno.py and verify-kagent-harness.py import that list for renders with a much smaller component set, and an ingress.mode that disagrees with the components enabled fails the connectivity chart's guard.
…version, a pin on it is refused; verify-components-charts renders the whole roster and holds the BOM to it The wiring chart is published off the same tag as the meta chart, yet its versionRange was a range of its own that a BOM pinned separately, so every BOM's connectivity lagged the moment the meta chart moved — three releases in a row forwarded a key the pinned connectivity's closed schema refused (#431, #441, #339), and the example BOM's own pin was fourteen releases behind. components.agent-platform-connectivity is releasedWithChart: true with an empty versionRange. The OCIRepository carries the meta chart's own exact version (agent-platform.chartVersion: build metadata dropped, a pre-release kept — the derivation the self range already floors on), so Flux rolls the connectivity release exactly when the meta chart rolls, never ahead or behind. A versionRange on such an entry is refused when it would pull from gitops.self.repository with no semverFilter — the lagging pin; a semverFilter (a dev channel) or another repository (a chart pushed by hand) keep their knobs. The example BOM no longer pins connectivity; the ATS points the component at the in-cluster registry only and lets the version derive. tests/verify-components-charts.py takes its roster from values.yaml (every components.* entry with a chart) and holds the BOM to it both ways; the BOM and the roster are read as YAML; the BOM pin is compared with the render and rendered with the BOM render's values; a pin no registry publishes fails instead of falling back; every Helm call is bounded; one temp dir; the stale UNRELEASED/RENDER_AGAINST entries go. tests/verify-components.py asserts the derivation on a packaged 4.99.0-test.1+abc123, the one Chart.yaml version, the refused pin and the two admitted shapes.
513f432 to
28d2ce8
Compare
|
Taken over from @marians (thanks for the handover). The head now carries the chart-side fix on top of the check; CI is green including agentlab proof — a second lab following this branch's dev channel ( Every HelmRelease of the lab Ready (12/12); Follow-ups filed: #467 (the meta render's cluster shape and the substrate bundled-Postgres shape are not rendered against any chart), #468 (parallelise the pulls). |
Follow-up to #278, taken over from @marians. Two changes, the first the root cause behind the second.
agent-platform-connectivityfollows the meta chart's own versionThe wiring chart is published off the same tag as the meta chart — two charts, one commit, one version — yet
components.agent-platform-connectivity.versionRangewas a range of its own (>=4.0.0 <5.0.0) that a BOM pinned separately. Every BOM's connectivity lagged the moment the meta chart moved: three releases in a row forwarded a key the pinned connectivity's closed schema refused (#431gateway.parameters.podAnnotations, #441vm-manager/vmManager, #339postgres.affinity/imagePullSecrets) and the release failed on every BOM-pinned installation. The example BOM's own pin (4.11.0) was fourteen releases behindmain— on this branch's merge-base, the published 4.11.0 rejects the forwarded values at/postgres, and no check could see it because the check rendered the working tree instead.The entry is now
releasedWithChart: truewith an emptyversionRange:agent-platform.chartVersion, build metadata dropped, a pre-release kept; the same derivation the self range already floors on — so Flux rolls the connectivity release exactly when the meta chart rolls, never ahead or behind;versionRangeon such an entry is refused when it would pull from the repository this chart's releases come from (gitops.self.repository) with nosemverFilter— that is the lagging pin; the two development shapes keep their knobs: asemverFilter(a dev channel, the lab following a branch) or anotherrepository(a chart pushed by hand: the ATS's in-cluster registry, a lab registry);examples/customer-bom.yamlno longer pins connectivity andtests/verify-components.pyrefuses one in it; it asserts the derivation on a chart packaged as4.99.0-test.1+abc123(→4.99.0-test.1), that the twoChart.yamlversions are one, the refused pin and the two admitted shapes;Every installation sees its connectivity OCIRepository move from the range to the exact version of the meta chart it runs (UPGRADE.md): the chart the range resolved to already for an installation on the current release, an upgrade for one whose connectivity lagged.
verify-components-chartsrenders the whole roster and holds the BOM to itThe check walked thirteen components named in the script;
agent-platform-connectivity,klaus-gateway,muster,agentgateway,valkey,agent-platform-mcps,agent-sandbox,dicebearandvm-managerwere never rendered — all three of #278's breaks were in that blind spot. The set is now the meta chart's own roster (everycomponents.*entry of values.yaml with achart), and the BOM must match it both ways: a roster entry the BOM does not pin, a pin that names no component, a pin the render carries differently than the BOM's line, a pin no registry publishes, and a pin on a chart released with the meta chart each FAIL.Every component is rendered at the range's resolution with the defaults' forwarded values and at the BOM pin with the BOM render's forwarded values (one render when both agree); connectivity, released with the chart, from the working tree. The BOM and the roster are read as YAML (PyYAML is in the CI image), every Helm call is bounded, the stale
UNRELEASED/RENDER_AGAINSTentries are gone (a BOM pin never falls back; a range ahead of its release still does whileUNRELEASEDnames it).tests/verify-bom-charts.pyand itsverify-metastep are removed — this check does strictly more, and carries its BOM-completeness guard, its pin-reaches-the-render assertion and its working-tree rule.22 components, 43 renders.
Verification
make verify-components verify-meta verify-self verify-components-chartsand the rest of thetest-ingress-modestarget list pass locally;pre-commit run --all-filesclean.--set components.agent-platform-connectivity.versionRange=4.11.0→pins a chart that is released with this chart: its version is this chart's own (1.1.35) …; with asemverFilteror anotherrepositorythe pin renders. A BOM copy with a connectivity line, a missing pin, a range as a pin, a pin in another spelling, and a pin no registry publishes each FAIL the check with the reason.components.agent-platform-connectivity.versionRange(management-cluster-bases, shared-configs, every customer configs repository), so the refused pin fires nowhere on the upgrade.execute-chart-tests) on this PR: the derived version against a real source-controller with the candidate's pre-release version.Follow-ups (filed)
autoknobs resolve without--api-versions), so the fleet shape's forwarded values — 16 of 22 components differ — are not rendered against any chart; the substrate block's bundled-Postgres shape neither;Checklist
values.yamlandvalues.schema.jsonare valid.