Skip to content

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

Merged
teemow merged 2 commits into
mainfrom
test/components-charts-from-bom
Sep 15, 2026
Merged

teemow merged 2 commits into
mainfrom
test/components-charts-from-bom

Conversation

@marians

@marians marians commented Sep 14, 2026

Copy link
Copy Markdown
Member

Follow-up to #278, taken over from @marians. Two changes, the first the root cause behind the second.

agent-platform-connectivity follows the meta chart's own version

The wiring chart is published off the same tag as the meta chart — two charts, one commit, one version — yet components.agent-platform-connectivity.versionRange was 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 (#431 gateway.parameters.podAnnotations, #441 vm-manager/vmManager, #339 postgres.affinity/imagePullSecrets) and the release failed on every BOM-pinned installation. The example BOM's own pin (4.11.0) was fourteen releases behind main — 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: 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 same 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 the repository this chart's releases come from (gitops.self.repository) with no semverFilter — that is the lagging pin; the two development shapes keep their knobs: a semverFilter (a dev channel, the lab following a branch) or another repository (a chart pushed by hand: the ATS's in-cluster registry, a lab registry);
  • examples/customer-bom.yaml no longer pins connectivity and tests/verify-components.py refuses one in it; it asserts the derivation on a chart packaged as 4.99.0-test.1+abc123 (→ 4.99.0-test.1), that the two Chart.yaml versions are one, the refused pin and the two admitted shapes;
  • the ATS smoke and own-flux scenarios point the component at the in-cluster registry and let the version derive — a real source-controller resolving an exact pre-release version.

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-charts renders the whole roster and holds the BOM to it

The check walked thirteen components named in the script; agent-platform-connectivity, klaus-gateway, muster, agentgateway, valkey, agent-platform-mcps, agent-sandbox, dicebear and vm-manager were never rendered — all three of #278's breaks were in that blind spot. The set is now the meta chart's own roster (every components.* entry of values.yaml with a chart), 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_AGAINST entries are gone (a BOM pin never falls back; a range ahead of its release still does while UNRELEASED names it). tests/verify-bom-charts.py and its verify-meta step 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-charts and the rest of the test-ingress-modes target list pass locally; pre-commit run --all-files clean.
  • Negative controls, this branch: --set components.agent-platform-connectivity.versionRange=4.11.0pins a chart that is released with this chart: its version is this chart's own (1.1.35) …; with a semverFilter or another repository the 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.
  • Fleet: no GitOps repository pins components.agent-platform-connectivity.versionRange (management-cluster-bases, shared-configs, every customer configs repository), so the refused pin fires nowhere on the upgrade.
  • ATS (execute-chart-tests) on this PR: the derived version against a real source-controller with the candidate's pre-release version.
  • agentlab: see the comment below (a lab following this branch's dev channel).

Follow-ups (filed)

  • the meta renders here are the vanilla cluster shape (auto knobs 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;
  • the 21 tag-list fetches and 42 pulls run sequentially (~30 s in CI; a thread pool would make it ~6 s).

Checklist

  • Update changelog in CHANGELOG.md.
  • Make sure values.yaml and values.schema.json are valid.

@marians
marians requested a review from a team as a code owner September 14, 2026 12:46
@circleci-architect

circleci-architect Bot commented Sep 14, 2026

Copy link
Copy Markdown

Published Helm chart agent-platform

4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8
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.h28d2ce8

Posted by architect-orb · build 8020 · commit 28d2ce8 · updated in place on every push

@circleci-architect

circleci-architect Bot commented Sep 14, 2026

Copy link
Copy Markdown

Published Helm chart agent-platform-connectivity

4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8
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.h28d2ce8

Posted by architect-orb · build 8021 · commit 28d2ce8 · updated in place on every push

@marians
marians force-pushed the test/components-charts-from-bom branch from d6a3caa to 513f432 Compare September 15, 2026 05:17
@marians

marians commented Sep 15, 2026

Copy link
Copy Markdown
Member Author

Rebased onto main (10 commits). The tests/verify-bom-charts.py conflict was a modify/delete, and the modification is the interesting part.

#339 fixed a false positive in that script while this PR was open, and this PR needed it more than the original did. LOCAL_CHARTS says that 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 the commit — it must be rendered from the working tree, not from a published pin. Rendering a published one fails every change that adds a key to both charts at once, because the key exists nowhere but here until the tag is cut.

That rule is carried over, and connectivity's two axes collapse into one working-tree render:

ok: agent-platform-connectivity working tree (working tree '>=4.0.0 <5.0.0 (range), 4.11.0 (BOM pin)') renders the forwarded values (54 objects)

It is load-bearing today, not a precaution. With LOCAL_CHARTS emptied, the check fails immediately:

FAIL: agent-platform-connectivity 4.11.0 (the BOM pin '4.11.0') rejects the values the meta chart forwards to it
- at '/postgres': additional properties 'affinity', 'imagePullSecrets' not allowed

Those are #339's own keys, added to both charts in one commit. Without the carry-over this PR would have broken main the moment it merged — worth flagging as the one thing a reviewer should sanity-check, since it is the difference between this check helping and blocking every in-repo change to the connectivity chart.

Everything else survived: 22 components, both axes, and main's re-pins are picked up with no change to the script (Substrate 0.0.30-gs.1, vm-manager 0.20.2 from its new gsoci range, muster 5.19.10). The CHANGELOG entry moved to ### Changed and now records the inherited rule.

verify-meta, verify-components-charts, verify-kagent-netpol, verify-kagent-harness, verify-kyverno, verify-components, verify-modes, verify-global, verify-secrets, verify-managers, verify-postgres, verify-presets, verify-disruption, verify-substrate-store, verify-valkey, verify-migration and pre-commit run --all-files all pass.

marians and others added 2 commits September 15, 2026 09:07
…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.
@teemow
teemow force-pushed the test/components-charts-from-bom branch from 513f432 to 28d2ce8 Compare September 15, 2026 07:20
@teemow teemow changed the title test(meta): verify-components-charts covers every component the BOM pins, not a list kept by hand 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 Sep 15, 2026
@teemow

teemow commented Sep 15, 2026

Copy link
Copy Markdown
Member

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 execute-chart-tests (the ATS on kind lets the connectivity version derive and a real source-controller resolves the candidate's exact pre-release version).

agentlab proof — a second lab following this branch's dev channel (platform.chartBranch: test/components-charts-from-bom, resolved to 4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8), agentlab up waited for every component HelmRelease:

$ helm ls -A | grep agent-platform
agent-platform               agent-platform-4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8
agent-platform-connectivity  agent-platform-connectivity-4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8+7a9867f95f55

OCIRepository agent-platform-connectivity
  spec.ref.semver     4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8
  artifact.revision   4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8@sha256:7a9867f9…
  Ready               True

HelmRelease agent-platform-connectivity
  history[0].chartVersion  4.16.1-dev.test-compo--ts-from-bom.2026-09-15.07-20-07.h28d2ce8+7a9867f95f55
  Ready                    True — Helm install succeeded

Every HelmRelease of the lab Ready (12/12); agentlab platform-test PASS on all seven proofs. The published dev meta chart alone shows the same: helm template of agent-platform:4.16.1-dev…h28d2ce8 renders the connectivity OCIRepository at semver: "4.16.1-dev…h28d2ce8", and helm show chart finds the connectivity dev chart at exactly that version (the +7a9867f95f55 in helm-controller's history is the build metadata agent-platform.chartVersion drops).

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).

@teemow
teemow merged commit baaa5aa into main Sep 15, 2026
14 checks passed
@teemow
teemow deleted the test/components-charts-from-bom branch September 15, 2026 07:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants