Skip to content

cloud: let the environment override the cloud image and registry - #5130

Open
Brian-McM wants to merge 1 commit into
tigera:masterfrom
Brian-McM:bm-cloud-hashrelease-image-override
Open

cloud: let the environment override the cloud image and registry#5130
Brian-McM wants to merge 1 commit into
tigera:masterfrom
Brian-McM:bm-cloud-hashrelease-image-override

Conversation

@Brian-McM

Copy link
Copy Markdown
Contributor

Description

Type of fix: build system change, no runtime behaviour change.

The VARIANT=cloud block pinned BUILD_IMAGE, IMAGE_REGISTRY and PUSH_IMAGE_PREFIXES with
:=, and a Makefile assignment overrides the environment. That is what we want for a cloud release
— it should always land in gcr.io/tigera-tesla/operator-cloud — but it left no way to build the
cloud variant into a different registry. A Calico Enterprise hashrelease passes the hashrelease
registry and image name through the environment (REGISTRY / IMAGE_NAME, which the release tool
turns into IMAGE_REGISTRY / BUILD_IMAGE), and those were silently replaced with the tigera-tesla
values.

This moves the cloud block above the enterprise defaults and switches those three to ?=, so:

  • an environment override wins (hashreleases can target their own registry),
  • the cloud values still apply when there is no override (make release-tag VARIANT=cloud is
    unchanged),
  • enterprise/OSS builds are untouched.

ARCHES deliberately stays := — the cloud variant is amd64 only by construction, and push-all
iterates ARCHES, so it must not pick up arches that were never built.

Why now: tigera/calico-private is adding the cloud operator image to enterprise hashreleases. It
needs the image to land next to the enterprise operator in the hashrelease registry, both to keep
dev artifacts out of the cloud release registry and because the hashrelease CI job's OIDC service
account is scoped to the hashrelease project, not tigera-tesla.

Testing

Verified variable resolution for all three paths by evaluating the Makefile directly:

BUILD_IMAGE IMAGE_REGISTRY ARCHES CLOUD_LDFLAGS
enterprise (no VARIANT) tigera/operator quay.io all four empty
VARIANT=cloud tigera-tesla/operator-cloud gcr.io amd64 set
VARIANT=cloud + env override tigera/operator-cloud gcr.io/unique-caldron-775/cnx amd64 set

hack/release unit tests pass.

Release Note

None

For PR author

  • Tests for change. (Makefile change; verified by evaluating all three variable-resolution paths, see above. No Go code changed.)
  • If changing pkg/apis/, run make gen-files (n/a)
  • If changing versions, run make gen-versions (n/a)

🤖 Generated with Claude Code

The VARIANT=cloud block pinned BUILD_IMAGE, IMAGE_REGISTRY and
PUSH_IMAGE_PREFIXES with `:=`, which overrides the environment. That is
right for a cloud release, but it left no way to build the cloud variant
into another registry: a Calico Enterprise hashrelease passes the
hashrelease registry and image via the environment and had them silently
replaced with gcr.io/tigera-tesla/operator-cloud.

Move the block above the enterprise defaults and use `?=` so an
environment override wins, the cloud values apply when there is none, and
enterprise builds are unchanged. ARCHES stays `:=` — the cloud variant is
amd64 only by construction.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants