Skip to content

ci: build each release image once and unblock the independent release jobs - #486

Open
boddumanohar wants to merge 5 commits into
mainfrom
ci/parallelize-release-pipeline
Open

boddumanohar wants to merge 5 commits into
mainfrom
ci/parallelize-release-pipeline

Conversation

@boddumanohar

@boddumanohar boddumanohar commented Sep 4, 2026

Copy link
Copy Markdown
Member

What

Turns Repo: Release from one long serial chain into a dependency graph, and builds each operator image once instead of twice.

setup
  ├─ build-atlas ──┬─ build-csi ────────────────────────────┐
  │                └─ build-operator ─┬─ release-operator ──┤ (OLM bundle)
  │                                   └─ package-operator-chart ─┐
  └─ package-csi-chart ──────────────────────────────────────┴─ merge-helm ─┴─ release-helm (FTPS publish)

Key changes

  • Build once. operator_build.yaml builds the operator and rebalancer images once, to DockerHub + ECR. operator_release.yaml retags that same multi-arch manifest to Quay (docker buildx imagetools create, no rebuild) before generating the OLM bundle — Quay is only ever written to during a release, never on a plain branch push.
  • Independent jobs run in parallel. build-csi and build-operator no longer serialize; release-operator and package-operator-chart both hang off build-operator instead of queuing behind each other.
  • VERSION label fixed. The OCI version label now tracks the real release tag instead of a hardcoded 0.1.0, and the rebalancer image gets it too.

Testing

  • Workflow YAML parses; the needs: graph matches the diagram above.
  • .claude/skills/house-style/scripts/quality-gate.sh --changed — all 9 gates pass.
  • Not exercised end to end: only takes effect on the next v* tag. Worth a throwaway tag before trusting it for a real release.

🤖 Generated with Claude Code

Repo: Release used to be one long conga line that built the operator
and rebalancer images twice. Now each image is built once, pushed
straight to Quay from the build (no second buildx round-trip just to
reach it), and everything that doesn't touch an image runs alongside
the builds instead of behind them. The OLM bundle and the operator
chart both wait on the operator images (nothing else) and race each
other; only the final FTPS publish waits on everything.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@boddumanohar
boddumanohar force-pushed the ci/parallelize-release-pipeline branch from 750371a to fa312f0 Compare September 8, 2026 08:58
@noctarius
noctarius force-pushed the main branch 2 times, most recently from 60dceb7 to fbaabe4 Compare September 9, 2026 10:21
boddumanohar and others added 4 commits September 10, 2026 15:02
Quay is where the OLM bundle resolves image digests from, so it only
needs a tag when the operator build runs as part of an actual release
(this job invoked via workflow_call from repo_release.yaml's v* tag
trigger). Gate the Quay login and the Quay tag out of DockerHub/ECR
pushes made on ordinary branch pushes.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…mage

operator_build.yaml goes back to DockerHub + ECR only, dropping the
conditional Quay push added in the previous commit. Quay only matters
for a release (make bundle resolves image digests straight from its
registry API), so keep it entirely out of the build workflow, which
also runs on every plain branch push.

operator_release.yaml now retags the already-built DockerHub manifest
to Quay with `docker buildx imagetools create` before generating the
bundle. This copies the multi-arch manifest across registries without
rebuilding, so the image is still built exactly once; Quay is written
to only during a release-operator run.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
release-operator populates Quay itself now, by retagging build-operator's
DockerHub images, rather than build-operator pushing there directly. Update
the comment above release-operator to describe that instead of the old
(now incorrect) claim that build-operator writes to Quay.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The comments across operator_build.yaml, operator_release.yaml, and
repo_release.yaml restated structure the code already makes clear.
Cut them down to the one non-obvious reason each job or step needs,
dropping the rest.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.

1 participant