fix(build): honor CODEGEN_IMAGE in Makefile codegen target

[anxkhn]

What

The generated-files workflow builds the codegen image once, with GitHub Actions
layer caching, and loads it into the daemon as codegen-env:latest:

# .github/workflows/generated_files.yml
- name: Build codegen image with caching
  uses: docker/build-push-action@v6
  with:
    context: .
    file: codegen.Dockerfile
    tags: codegen-env:latest
    load: true # makes the image available for `docker run`
    cache-from: type=gha
    cache-to: type=gha,mode=max

- name: Run codegen
  run: CODEGEN_IMAGE=codegen-env:latest make codegen

The CODEGEN_IMAGE=codegen-env:latest prefix is meant to make make codegen
reuse that pre-built, cache-warmed image instead of building it again. But the
codegen target no longer reads CODEGEN_IMAGE; it always runs its own
docker build:

codegen:
	@echo "Building codegen image"
	docker build -q -t codegen-env . -f codegen.Dockerfile
	@echo "Generating code"
	docker run -v $$PWD:/workspace codegen-env make generate

So the variable is a no-op today: CI rebuilds the image from scratch on every run
and the buildx caching step above serves no purpose. grep -rn CODEGEN_IMAGE
(excluding node_modules) currently returns a single hit, the workflow line,
with nothing consuming it.

How this happened

CODEGEN_IMAGE was originally introduced on both sides in the same change (the
workflow began passing it and the Makefile honored it via a
$${CODEGEN_IMAGE:-$$(docker build ...)} fallback), sitting next to the buildx
cache step. A later "simplify codegen" change rewrote the codegen target to the
hardcoded docker build -q -t codegen-env form and dropped the variable, but the
workflow kept passing it, leaving the two sides out of sync.

The fix

Skip the docker build and run the caller-supplied image when CODEGEN_IMAGE is
set, falling back to a locally built codegen-env otherwise:

codegen:
	@if [ -z "$$CODEGEN_IMAGE" ]; then \
		echo "Building codegen image"; \
		docker build -q -t codegen-env . -f codegen.Dockerfile; \
	fi
	@echo "Generating code"
	docker run -v $$PWD:/workspace $${CODEGEN_IMAGE:-codegen-env} make generate

This keeps make codegen self-contained for local use (unchanged behavior when
CODEGEN_IMAGE is unset) while letting CI consume the image it already built and
cached. It restores the pre-simplification semantics in the current target's
readable multi-line style, so no workflow change is needed.

Behavior

• Local dev (make codegen, no variable): builds codegen-env, then runs it.
  Unchanged.
• CI (CODEGEN_IMAGE=codegen-env:latest make codegen): skips the build and runs
  the pre-built codegen-env:latest, reusing the buildx GHA cache.

The generated output is identical either way (same image contents, same
make generate), so the "Check for uncommitted changes" step is unaffected. The
Generated files job itself is the regression guard here and stays green.

Alternative considered

The mechanical alternative is to drop the now-dead prefix from the workflow
(run: make codegen), which also makes the two sides consistent. I went with
restoring CODEGEN_IMAGE instead because the buildx cache step and its
load: true comment ("makes the image available for docker run") exist
specifically to feed a reused image; dropping the prefix would leave that step
building an image nothing consumes. Happy to switch to the workflow-only change
if you'd rather keep the codegen target strictly hardcoded.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[changeset-bot]

⚠️ No Changeset found

Latest commit: c197181

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR