agent-platform release v4.17.0

Changed

• agent-platform-connectivity follows the meta chart’s own version; a pin on it is refused (giantswarm/agent-platform#450, the root cause behind #431, #441 and #339). The wiring chart is published off the same git tag as this chart — two charts, one commit, one version — yet its versionRange was a range of its own (>=4.0.0 <5.0.0) 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 (gateway.parameters.podAnnotations, vm-manager / vmManager, postgres.affinity / imagePullSecrets) that the pinned connectivity’s closed schema refused, and the release failed on every BOM-pinned installation. The example BOM’s own pin was fourteen releases behind. The connectivity entry is now releasedWithChart: true with an empty versionRange: the meta chart renders the OCIRepository at its own exact version (agent-platform.chartVersion — build metadata dropped, a pre-release kept, the same derivation the self range floors on), so Flux rolls the connectivity release exactly when the meta chart rolls and 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 for a dev channel, another repository for 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; the ATS smoke and own-flux scenarios point the component at the in-cluster registry and let the version derive, proving it against a real source-controller with a pre-release version. Every installation sees its connectivity OCIRepository move from the range to the exact version of the meta chart it runs — the same chart the range resolved to for an installation on the current release, an upgrade for one whose connectivity lagged (UPGRADE.md).
• make verify-components-charts renders every component of the meta chart’s roster, and the BOM has to pin all of it (giantswarm/agent-platform#278 follow-up, #450). The check rendered thirteen components named in the script — the seven extras, the two managers, the kagent and Substrate lines — 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 them; that list is exactly what let #278’s three breaks reach main. The set is now the meta chart’s own roster (every components.* entry of values.yaml with a chart), and examples/customer-bom.yaml 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); agent-platform-connectivity, released with the chart, is rendered from the working tree — the pair an installation gets is always the pair in the commit, and a key added to both charts at once exists nowhere else until the tag is cut (#339). The BOM and the roster are read as YAML (PyYAML is in the CI image), every Helm call is bounded, and the four UNRELEASED entries whose releases exist are gone: a range that admits nothing published is still rendered against the newest chart the line has while UNRELEASED names the release it waits for, a BOM pin never is. 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, deliberately apart from QUICKSTART, which tests/verify-kagent-tools-namespace.py imports for renders with a much smaller component set. 22 components, 43 renders.

Removed

• tests/verify-bom-charts.py and its make verify-meta step (giantswarm/agent-platform#450; added by #278, carried #339’s working-tree rule for the connectivity chart). make verify-components-charts does strictly more: it renders the charts through where that one only proved the schema accepted the values (reporting the rest as needs-input), it covers the range’s resolution as well as the pin, and it renders the pin with the BOM render’s forwarded values. The BOM-completeness guard, the pin-reaches-the-render assertion and the working-tree rule moved with it.