Deliver several repos as one chart

A Product with several repos, such as a web app and its API, can ship them together. With umbrella delivery, each Release is one version of the Product's umbrella chart: every repo's newest build, or its previous image carried when it has no new build. Every environment then deploys that chart version, so one version names everything that runs there, and a rollback puts back the previous version as a whole.

The other strategy, isolated delivery, is the default: a Release ships one commit of one repo and pins its image into each environment (Deliver a single app).

	Isolated (default)	Umbrella
A Release ships	One commit of the delivery repo (spec.delivery.repo, else the first)	One version of the umbrella chart, with every repo's image
Its version	A tag vX.Y.Z on the delivery repo	A tag <product>-X.Y.Z on the chart in the org's charts repo
An environment deploys	The generic chart in the gitops repo, with the release's image	The umbrella chart at its tag, with the environment's own values
A rollback puts back	The previous image	The previous chart version: every repo's previous image
Agents that run when a release is cut (release.cut)	Started	Not started yet

Turn it on

On the Product's page, open Settings (the cog by its name), then Delivery, and choose Umbrella. The panel lists what each release would pin. Only org admins can change it, and the change takes effect at the next release: until then every environment keeps what it runs. Moving back to Isolated works the same way: the next release points each environment at the generic chart again.

Through the API, set spec.delivery.strategy to umbrella (or back to isolated) with replace-product.

What a release does

1. Resolves every repo. The delivery repo builds in the Product's kpack Image, every other repo in its own, <product>-<repo>. Infrared adds those Images for a Product it scaffolded; for any other, create them with those names. A repo whose newest build differs from the chart's pin is changed; the others are carried. A release with nothing changed is refused.
2. Tags each changed build with the version, by digest, as an isolated release tags its one image.
3. Writes the chart. charts/<product> in the org's charts repo, which Infrared creates. The chart is the generic web chart from the gitops repo (products/<product>/chart), copied at each release: the delivery repo runs from the chart itself, and every other repo from its own copy under charts/<repo>, with a Deployment and Service named <product>-<repo>. Infrared commits the version and the pins and tags the commit <product>-<version>.
4. Promotes it environment by environment, as for isolated delivery: a pull request to the gitops repo points the environment's Application at the chart's tag, Argo CD runs it, and the release guard checks it. The environment counts as running the release only when every repo's image runs there.

Edit the templates in the gitops repo, not in the charts repo: each release copies them again. Each environment keeps its own values file, products/<product>/zones/<zone>/values.yaml, as before.

A check for another repo of the Product reaches it at http://<product>-<repo>.<zone>.svc/.

Rollback

When an environment fails its release guard and rolls back, Infrared opens and merges a pull request that points its Application back at the previous chart tag, waits for Argo CD to run every image of that version, and marks the environment Rolled back to that version. As with isolated delivery, data is never rolled back.

On the Releases tab

The Versions view lists each release's chart version, linked to its tag, and its repos: the changed ones first with how many commits each gained, then the carried ones folded under carried. A repo whose build the release still waits for reads building. See Products.

The control plane as an environment

The platform org's own Infrared is delivered the same way: an umbrella Product whose one environment has target: controlPlane. Each release copies the changed components' images to a release registry, commits their pins and the version to the umbrella chart, pushes the chart to an OCI registry (spec.delivery.charts), and after approval upgrades the control plane to it. That environment's release guard is the upgrade guard: a Job running the operator that was there before, so a broken new operator can't keep it from rolling back. It checks Argo CD, every Deployment of Infrared, the gitops repo and the environment's own checks for two minutes, reads the control plane's SLOs over that time with the same error budget check as any environment (its uptime and the edge's errors and latency for Infrared's own address, recorded but never paged on), and rolls the upgrade back if they don't pass within controlPlane.guardTimeout. A connection the edge resets is tried again at once, so one reset doesn't restart the two minutes. Releasing and approving take the Product's own roles, as for any environment; only the platform org may hold such an environment. See the CRD reference.

Limits

• Argo CD must be able to read the org's charts repo. On an org whose gitops repo and Products share a forge, the org's repository credentials cover it. Infrared adds the charts repo to the products AppProject's sources when none matches it.
• Every repo builds with the Product's scaffold kind (static, node or go) and is served on port 8080 with the generic chart's defaults. Per-repo settings (replicas, resources, environment variables) apply to the delivery repo only.
• A repo can't be named after a key of the generic chart's values (image, replicas, port, env and the like).
• Releases of an umbrella Product don't start release.cut agent workflows, such as release notes and announcements.