agent-platform release v4.7.7
Fixed
- Uninstalling the platform through a cluster’s own Flux no longer races the Substrate CRD chart (giantswarm/agent-platform#385). With the engine off nothing orders the component uninstalls — helm-controller finalizes the platform
HelmReleases the chart rendered concurrently — and substrate-crds could go before substrate, whose uninstall then failed for good on its SandboxConfig (failed to delete release: substrate: Helm cannot delete an object whose kind is gone) and was retried until the meta HelmRelease’s finalizer timed out (measured on the ATS own-Flux scenario, PR #380). The Substrate line re-pins to v0.0.27-gs.3 (components.substrate/substrate-crds >=0.0.27-gs.3 <0.0.28-0, kagent.substrateWorkerPool.workerImage 0.0.27-gs.3, examples/customer-bom.yaml, tests/verify-components.py): its one new carried patch (giantswarm/substrate#12, upstream-first, prepared for kagent-dev/substrate in giantswarm/giantswarm#37742 row 28) puts helm.sh/resource-policy: keep on the three ate.dev CRD templates, set at the generator as the kagent line does (giantswarm/kagent-upstream#10) — so every CRD chart of the platform keeps its CRDs and a consumer’s uninstall can always delete its CRs, whatever order the releases go in. The ATS own-Flux scenario’s way back is a test now (test_the_way_back_uninstalls_through_the_clusters_flux): the meta HelmRelease deleted, every platform release uninstalled concurrently by the cluster’s Flux with no UninstallFailed, the eight kept CRDs in place, no SandboxConfig or WorkerPool left — the delete_platform_releases_in_waves workaround is gone; the smoke’s ordered teardown asserts the same keep policy on ate.dev. Rejected: rendering the teardown-releases hook with the engine off (a cluster-admin hook in the fleet render for an order that stops mattering) and waiting for a Flux-side reverse-dependsOn uninstall (upstream’s open fluxcd/flux2#1744). README “Clusters that run Flux”, “Uninstalling”, “CRD lifecycle” and UPGRADE.md describe the uninstall order and what a kept CRD implies. No installation acts — the release stays inert behind the fleet’s <4.0.0 bound.