ci: cache orchestrator-runtime image build via GHA cache

[renecannao]

Summary

• Follow-up to ci: fix lint on push/schedule and bake orchestrator test runtime image #96. The prior change eliminated the silent apt-at-runtime, but each of 12 matrix jobs still re-ran apt-get install on every CI run, and we already saw one PR fail when archive.ubuntu.com hung for 116s on a single job (exit code 100 from docker build).
• Switch the three Build orchestrator runtime image steps from raw docker build to docker/build-push-action@v6 with cache-from/cache-to: type=gha,scope=orchestrator-runtime. After the first successful build, every subsequent job restores the image from the GitHub Actions cache and skips apt entirely — apt only runs again when the Dockerfile changes.

Test plan

• First run on this PR: one job populates the GHA cache, the rest restore it (visible as "importing cache manifest"/"CACHED" lines in build logs)
• Functional Tests matrix is green
• Subsequent runs complete the image build step in seconds, not the ~20-120s apt takes

Summary by CodeRabbit

• Chores
  • Optimized continuous integration build process infrastructure with improved caching mechanisms and enhanced deployment capabilities.

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[coderabbitai]

📝 Walkthrough

Walkthrough

The pull request replaces Docker build commands in GitHub Actions workflow with a modern two-step process: setting up Docker Buildx and using the Docker build-push action with caching capabilities.

Changes

Cohort / File(s)	Summary
CI/CD Workflow Docker Build .github/workflows/functional.yml	Replaced direct docker build commands with docker/setup-buildx-action@v3 and docker/build-push-action@v6 for orchestrator-runtime image builds across functional-test jobs, adding GitHub Actions cache configuration and registry-agnostic image loading.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• ci: fix lint on push/schedule and bake orchestrator test runtime image #96: Related PR that previously modified the functional workflow's orchestrator-runtime image build process; this PR introduces a more advanced build approach using Docker Buildx with caching.

Poem

🐰 Docker builds so swift and clean,
With Buildx magic in between,
Cache flows fast through Actions' way,
Faster tests to save the day! 🚀

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: replacing docker build steps with GitHub Actions caching for the orchestrator-runtime image build.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci-cache-runtime-image

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (2)

.github/workflows/functional.yml (2)

58-69: Consider deduplicating the repeated Buildx/build step block.

The same block appears in three jobs; extracting it into a reusable workflow/composite action (or YAML anchor) would reduce drift risk when you tweak cache/tag/build settings later.

Also applies to: 202-213, 336-347

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/functional.yml around lines 58 - 69, The "Set up Docker
Buildx" and "Build orchestrator runtime image" steps are duplicated across
multiple jobs; refactor them into a single reusable unit (either a reusable
workflow or a composite action / YAML anchor) and replace the repeated blocks
with calls to that unit to avoid drift. Locate the steps named "Set up Docker
Buildx" and "Build orchestrator runtime image" in the workflow, extract their
uses: docker/setup-buildx-action@v3 and docker/build-push-action@v6
configuration (context, file, tags, load, cache-from, cache-to) into the new
reusable workflow/composite action (or anchor), then update each job to invoke
the reusable workflow or reference the anchor so cache/tag/build settings are
maintained in one place.

---

58-69: If you want deterministic first-run cache hits, add a dedicated cache-prewarm job.

Because matrix jobs run in parallel, Line 68–69 cache population/restore timing can race on the first run. A small prewarm job (build runtime image once, then needs for matrix jobs) makes the “one job warms, others hit cache” behavior consistent.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/functional.yml around lines 58 - 69, Add a small dedicated
cache-prewarm job that builds the orchestrator runtime image once to populate
the GHA cache before matrix jobs run; create a job (e.g., name it cache-prewarm)
using docker/build-push-action@v6 with the same
context/tests/functional/orchestrator-runtime.Dockerfile, the same tags and
cache-to: type=gha,mode=max,scope=orchestrator-runtime so it writes the cache,
and then make your existing matrix job(s) that currently run the "Build
orchestrator runtime image" step declare needs: cache-prewarm so they run after
the prewarm and get deterministic first-run cache hits.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/functional.yml:
- Around line 58-69: The "Set up Docker Buildx" and "Build orchestrator runtime
image" steps are duplicated across multiple jobs; refactor them into a single
reusable unit (either a reusable workflow or a composite action / YAML anchor)
and replace the repeated blocks with calls to that unit to avoid drift. Locate
the steps named "Set up Docker Buildx" and "Build orchestrator runtime image" in
the workflow, extract their uses: docker/setup-buildx-action@v3 and
docker/build-push-action@v6 configuration (context, file, tags, load,
cache-from, cache-to) into the new reusable workflow/composite action (or
anchor), then update each job to invoke the reusable workflow or reference the
anchor so cache/tag/build settings are maintained in one place.
- Around line 58-69: Add a small dedicated cache-prewarm job that builds the
orchestrator runtime image once to populate the GHA cache before matrix jobs
run; create a job (e.g., name it cache-prewarm) using
docker/build-push-action@v6 with the same
context/tests/functional/orchestrator-runtime.Dockerfile, the same tags and
cache-to: type=gha,mode=max,scope=orchestrator-runtime so it writes the cache,
and then make your existing matrix job(s) that currently run the "Build
orchestrator runtime image" step declare needs: cache-prewarm so they run after
the prewarm and get deterministic first-run cache hits.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 93260ffc-a096-406c-b71f-2e6d0fc8a6a6

📥 Commits

Reviewing files that changed from the base of the PR and between a2c1dfd and 1f3f172.

📒 Files selected for processing (1)

• .github/workflows/functional.yml