Conversation
Add a reusable GitHub Actions workflow to build and push Docker images for the indexer, API, and frontend services to GitHub Container Registry (GHCR) on every push to main. Images are built for both linux/amd64 and linux/arm64 platforms.
📝 WalkthroughWalkthroughCI workflow split backend into separate format, lint, and test jobs and adds a reusable Docker build-and-push workflow plus a new "Docker (GHCR)" CI job that dispatches per-app multi‑platform image builds to the reusable workflow on pushes to main. Changes
Sequence Diagram(s)sequenceDiagram
participant CI as CI (ci.yml)
participant Reusable as Reusable Workflow (docker-build-push.yml)
participant Buildx as Docker Buildx / build-push-action
participant GHCR as GitHub Container Registry
CI->>Reusable: dispatch with inputs (image-tag, apps)
Reusable->>Buildx: checkout repo & setup buildx
Reusable->>Buildx: start matrix build per app (context, dockerfile, optional target)
Buildx->>GHCR: login (ghcr.io)
Buildx->>GHCR: push multi-arch images (ghcr.io/{owner}/{app.name}:{image-tag})
GHCR-->>Reusable: accept/persist images
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/workflows/docker-build-push.yml (1)
48-48: Add an immutable image tag alongsidemain.Using only a mutable tag makes rollback/debugging harder. Keep
main, but also publish${{ github.sha }}.Suggested fix
- tags: ghcr.io/${{ github.repository_owner }}/${{ matrix.app.name }}:${{ inputs.image-tag }} + tags: | + ghcr.io/${{ github.repository_owner }}/${{ matrix.app.name }}:${{ inputs.image-tag }} + ghcr.io/${{ github.repository_owner }}/${{ matrix.app.name }}:${{ github.sha }} ... - tags: ghcr.io/${{ github.repository_owner }}/${{ matrix.app.name }}:${{ inputs.image-tag }} + tags: | + ghcr.io/${{ github.repository_owner }}/${{ matrix.app.name }}:${{ inputs.image-tag }} + ghcr.io/${{ github.repository_owner }}/${{ matrix.app.name }}:${{ github.sha }}Also applies to: 58-58
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/docker-build-push.yml at line 48, The workflow currently only pushes a mutable tag via the tags setting; add a second immutable tag using the commit SHA by including both tags for the image push (keep the existing tag using inputs.image-tag or "main" and also add ghcr.io/${{ github.repository_owner }}/${{ matrix.app.name }}:${{ github.sha }}), ensuring the push action receives an array of tags so both are published; apply the same change to the other tags occurrence referenced in the diff.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/ci.yml:
- Around line 67-70: The docker job is gated only by an if condition and can run
without waiting for other jobs; add an explicit dependency by adding needs:
[backend, frontend] to the docker job definition (the job with name/key "docker"
that uses ./.github/workflows/docker-build-push.yml) so that the Docker publish
step only runs after the backend and frontend jobs complete successfully.
In @.github/workflows/docker-build-push.yml:
- Around line 29-30: The workflow is missing QEMU emulation which breaks
multi-arch builds; add a step using docker/setup-qemu-action (e.g., uses:
docker/setup-qemu-action@v2) immediately before the "Set up Docker Buildx" step
so the runner can emulate arm64 when building the linux/amd64,linux/arm64
targets on ubuntu-latest; ensure the new step runs on the same job and is
positioned before docker/setup-buildx-action@v3.
---
Nitpick comments:
In @.github/workflows/docker-build-push.yml:
- Line 48: The workflow currently only pushes a mutable tag via the tags
setting; add a second immutable tag using the commit SHA by including both tags
for the image push (keep the existing tag using inputs.image-tag or "main" and
also add ghcr.io/${{ github.repository_owner }}/${{ matrix.app.name }}:${{
github.sha }}), ensuring the push action receives an array of tags so both are
published; apply the same change to the other tags occurrence referenced in the
diff.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 93f90b65-b797-4359-93b0-e2e2d4d9074e
📒 Files selected for processing (2)
.github/workflows/ci.yml.github/workflows/docker-build-push.yml
Split backend job into backend-fmt, backend-clippy, backend-test to match PR #20 structure. The docker job now requires all four CI jobs (backend-fmt, backend-clippy, backend-test, frontend) to pass before building and pushing images to GHCR.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/ci.yml (1)
14-74: Optional: reduce backend job duplication with a matrix/composite step.
checkout/Rust setup/cache boilerplate is repeated across backend jobs; consolidating this would make future CI changes easier to maintain.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml around lines 14 - 74, Multiple backend jobs (backend-fmt, backend-clippy, backend-test) repeat the same Checkout, Setup Rust, and Cache Cargo steps; extract those into a reusable unit by creating either a composite action or a shared job used via a workflow call or job matrix. Replace duplicated steps in backend-fmt, backend-clippy, and backend-test with a single invocation that performs Checkout (actions/checkout@v4), Setup Rust (dtolnay/rust-toolchain@stable with appropriate components), and Cache Cargo (Swatinem/rust-cache@v2) so each job only runs its unique step (Format/Clippy/Test); ensure the new composite action or called job exposes inputs for the working-directory and rust components so backend-fmt, backend-clippy, and backend-test can pass different args (e.g., rustfmt vs clippy vs none) and preserve existing defaults.
🤖 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/ci.yml:
- Around line 14-74: Multiple backend jobs (backend-fmt, backend-clippy,
backend-test) repeat the same Checkout, Setup Rust, and Cache Cargo steps;
extract those into a reusable unit by creating either a composite action or a
shared job used via a workflow call or job matrix. Replace duplicated steps in
backend-fmt, backend-clippy, and backend-test with a single invocation that
performs Checkout (actions/checkout@v4), Setup Rust
(dtolnay/rust-toolchain@stable with appropriate components), and Cache Cargo
(Swatinem/rust-cache@v2) so each job only runs its unique step
(Format/Clippy/Test); ensure the new composite action or called job exposes
inputs for the working-directory and rust components so backend-fmt,
backend-clippy, and backend-test can pass different args (e.g., rustfmt vs
clippy vs none) and preserve existing defaults.
Adds a reusable GitHub Actions workflow to automatically build and push Docker images for the indexer, API, and frontend services to GitHub Container Registry on every push to main.
Images are built for both linux/amd64 and linux/arm64 platforms using Docker Buildx. The workflow is triggered only on pushes to main and properly scoped permissions for reading code and writing to GHCR.
Summary by CodeRabbit