compose: drop shared image tag in dev to avoid buildx build conflict

[medihack]

Summary

• Fix Docker image naming conflict where multiple services competed for the same image name
• Add explicit unique image names to web, default_worker, dicom_worker, and receiver services
• Update CI to tag the single build with all 4 image names

Problem

When running docker compose up, services sharing the x-app anchor (web, default_worker, dicom_worker, receiver) would build simultaneously and compete for the same default image name, causing Docker to fail with:

failed to solve: image "adit_dev:latest": already exists

Additionally, CI builds a single image adit_dev:latest but Docker Compose (without explicit image: directives) expects service-specific names like adit_dev-web:latest, causing CI to fail with "No such image" errors.

Solution

Give each service an explicit, unique image name:

• adit_dev-web:latest
• adit_dev-default_worker:latest
• adit_dev-dicom_worker:latest
• adit_dev-receiver:latest

Since all services use identical builds (same Dockerfile, same target), CI builds once and tags the result with all 4 names - efficient and conflict-free.

Summary by CodeRabbit

• Chores
  • Updated development configuration to use per-service image overrides instead of a single global image declaration.
  • CI workflow updated to build and publish multiple service images (replaces single-image publish).

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[gemini-code-assist]

Summary of Changes

Hello @medihack, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refines the development Docker Compose configuration to resolve a known build conflict. By eliminating a specific, shared image tag, the system will now exclusively depend on the defined build instructions, thereby mitigating issues that can arise when buildx is used for development builds.

Highlights

• Docker Compose Configuration: The explicit image: adit_dev:latest tag has been removed from the x-app anchor in docker-compose.dev.yml.
• Build Conflict Resolution: This modification is intended to prevent build conflicts, particularly when utilizing buildx, by ensuring development builds do not rely on a shared image tag.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[coderabbitai]

Warning

Rate limit exceeded

@medihack has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 29 minutes and 12 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 49ebf2d and 9ccb8ac.

📒 Files selected for processing (1)

• .github/workflows/ci.yml

📝 Walkthrough

Walkthrough

Replaced a single shared image declaration with per-service image overrides in docker-compose.dev.yml and updated the CI workflow (.github/workflows/ci.yml) to build/push multiple image tags (adit_dev-web, adit_dev-default_worker, adit_dev-dicom_worker, adit_dev-receiver) instead of one adit_dev:latest.

Changes

Cohort / File(s)	Summary
Docker Compose docker-compose.dev.yml	Removed the global image: adit_dev:latest from the x-app default anchor and added explicit image entries per service: adit_dev-web:latest, adit_dev-default_worker:latest, adit_dev-dicom_worker:latest, adit_dev-receiver:latest. Other anchor keys (build, environment, command, healthcheck) unchanged.
CI workflow .github/workflows/ci.yml	Modified build/push step to publish multiple image tags (the four per-service images) instead of a single adit_dev:latest image. No other workflow steps changed.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐇 I hopped through YAML, neat and spry,
Four little names now reach the sky,
From one to many, tags in tune,
I cheer the change beneath the moon 🌙

Pre-merge checks

✅ 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 a shared Docker image tag with service-specific tags in the dev compose file to resolve a buildx build conflict.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

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.}

[gemini-code-assist]

Code Review

This pull request removes the shared image: adit_dev:latest tag from the x-app anchor in docker-compose.dev.yml. This is a correct and effective solution to prevent build conflicts when using buildx, which can occur when multiple services attempt to build and tag the same image concurrently. By removing this line, Docker Compose will default to creating uniquely named images for each service (e.g., project_web, project_worker), thus avoiding the race condition. This change improves the reliability of the local development environment setup. The implementation is sound, and I have no further recommendations.

[claude]

Code Review - PR #279

Summary

This PR removes the image: adit_dev:latest tag from the x-app anchor in docker-compose.dev.yml to resolve buildx build conflicts. The change is well-justified and correctly implemented.

Analysis

What Changed

• Removed: image: adit_dev:latest from the x-app anchor in docker-compose.dev.yml:1-2
• Impact: Services will now use auto-generated image names (e.g., adit_web, adit_default_worker) instead of a shared tag

Why This Matters

When using Docker Buildx or docker-compose with multiple services sharing the same image tag, build conflicts can occur because:

1. Multiple services (web, default_worker, dicom_worker, receiver, init) all inherit from x-app
2. They all try to build and tag as adit_dev:latest simultaneously
3. This creates race conditions and can cause build failures or cache inconsistencies

Code Quality: ✅ Excellent

• Minimal change: Only removes the problematic line
• Consistent with production: The production config (docker-compose.prod.yml:2) uses image: ghcr.io/openradx/adit:latest for pulling pre-built images, not for local builds
• Follows best practices: Docker Compose automatically generates unique image names per service when no explicit tag is provided

Potential Issues: ✅ None identified

• No breaking changes - services will still build correctly
• pull_policy: build ensures images are always built from source in dev
• The build.target: development directive is still present and functional

Performance Considerations: ✅ Improved

• Better cache utilization: Each service gets its own image tag, reducing cache invalidation conflicts
• Parallel builds: Services can now build in parallel without conflicts
• No performance regression: Auto-generated tags are equally efficient

Security Concerns: ✅ None

• This is a build configuration change with no security implications
• Dev environment only - production config unchanged

Test Coverage: ✅ Adequate

• This is infrastructure configuration, not application code
• Manual verification during local development would confirm the fix
• Recommendation: Test with docker-compose -f docker-compose.base.yml -f docker-compose.dev.yml up --build to ensure no regressions

Verdict

LGTM ✅ This is a focused, well-reasoned fix that addresses a real development workflow issue. The commit message clearly describes the problem and solution. No changes needed.

Minor Suggestion (Optional)

Consider documenting this change in KNOWLEDGE.md:89, where the old build command docker build . --target development -t adit_dev is referenced. Developers following that documentation might be confused why the tag is no longer in the compose file.

[claude]

Code Review for PR #279

Summary

This PR addresses a Docker Buildx build conflict by removing the shared image: adit_dev:latest tag from the x-app anchor in docker-compose.dev.yml and assigning unique image tags to each service (adit_dev-web:latest, adit_dev-default_worker:latest, etc.). The CI workflow has been updated accordingly to build all four image tags.

✅ Strengths

1. Problem-Solution Alignment: The change directly addresses the buildx conflict issue by ensuring each service has its own unique tag
2. Consistency: Both the CI workflow and docker-compose.dev.yml are updated in sync
3. No Breaking Changes: The change is backward-compatible and doesn't affect the production configuration

🔍 Code Quality & Best Practices

Good:

• The YAML formatting is clean and consistent
• The multiline tag format in the CI workflow follows Docker conventions
• All four services that need tags are properly covered

Considerations:

• The approach creates 4 separate image tags for what is essentially the same image (all built from the same development target). This works but may be slightly redundant from a storage perspective

🐛 Potential Issues

Minor Issue - Image Tag Redundancy:
All four services (web, default_worker, dicom_worker, receiver) are built from the same Dockerfile with the same development target, meaning they're identical images. The current approach tags the same image 4 times, which:

• Uses additional registry/cache space
• May cause confusion about whether these images are actually different

Alternative Approach to Consider:
You could potentially keep a single shared image tag and use the container_name directive to avoid conflicts, or use the pull_policy: build that's already present in the x-app anchor. However, if this approach solves your specific buildx issue, it may be the right pragmatic solution.

⚡ Performance Considerations

• Build Time: No negative impact - all images are built from the same layer cache
• Cache Efficiency: The GHA cache strategy (type=gha,mode=max) remains optimal
• Storage: Minor increase in tag metadata storage, negligible impact in practice

🔒 Security Concerns

No security issues identified. The changes are configuration-only and don't introduce any security risks.

🧪 Test Coverage

Missing Test Validation:
The PR description mentions this fixes a buildx conflict, but there's no explicit verification that:

1. The conflict is actually resolved
2. All four services can start successfully with their new tags
3. The --no-build flag in the CI workflow step works correctly with the pre-built tags

Recommendation:
Consider adding a comment in the PR description confirming that:

• The CI pipeline passes successfully
• All containers start correctly in the development environment
• The buildx conflict no longer occurs

📝 Additional Observations

1. docker-compose.dev.yml line 25: The init service still uses the <<: *default-app anchor but doesn't have an explicit image: tag. This appears intentional (it's in the never profile), but worth confirming this service doesn't need a tag.

2. Consistency with Production: The production compose file (docker-compose.prod.yml) uses a single shared image tag (ghcr.io/openradx/adit:latest). This inconsistency between dev and prod is worth documenting - though it makes sense given different deployment models.

✅ Recommendation

APPROVE with minor suggestions for improvement.

The changes are sound and solve the stated problem. The approach is pragmatic and doesn't introduce any significant issues. Consider:

1. Adding a note in the commit message or PR description explaining why separate tags are needed despite identical images
2. Verifying the CI passes completely with the new configuration
3. Confirming the init service behavior is as intended

📚 Style & Conventions

The changes align with the repository's conventions observed in other compose files. No style violations detected.

---

Review generated by Claude Code

[claude]

Code Review: PR #279

Summary

This PR addresses a legitimate Docker Compose image naming conflict when using BuildKit by assigning unique image names to each service. The solution is effective and well-documented.

---

✅ Strengths

1. Problem Well Identified: The PR correctly identifies and fixes the race condition where multiple services sharing the x-app anchor compete for the same image name during parallel builds
2. Efficient CI Solution: Building once and tagging with multiple names is the right approach - avoids redundant builds while satisfying Docker Compose's service-specific image naming expectations
3. Consistent Naming Convention: The naming pattern adit_dev-<service>:latest is clear and consistent across all four services
4. Good Documentation: PR description thoroughly explains both the problem and solution

---

🔍 Issues & Concerns

1. Missing init Service Image Name (High Priority)

The init service at docker-compose.dev.yml:25-27 also uses the <<: *default-app anchor but was not given an explicit image name. This creates an inconsistency:

• Current state: init service inherits the anchor without an image name
• Problem: Docker Compose will auto-generate a name like adit_dev-init:latest, but the CI workflow doesn't build/tag this image
• Impact: If the init service is ever used (currently has profiles: [never]), it will fail

Recommendation: Either:

• Add image: adit_dev-init:latest to the init service and add it to CI tags (if it might be used)
• Add a comment explaining why init is excluded from explicit naming (if it's truly never used)

2. Removal of fail-fast: false Strategy (Medium Priority)

The commit at 9ccb8ac removes the fail-fast strategy from CI:

-    strategy:
-      fail-fast: false

Concerns:

• This change is unrelated to the image naming fix
• No explanation in PR description or commit message
• The original fail-fast: false may have been intentional to see all test failures
• Currently there's only one job, so it has no effect, but could matter if jobs are added later

Recommendation:

• Either revert this change as out-of-scope, or
• Add explanation to PR description about why this was removed

3. Production Compose Not Updated (Low Priority - Informational)

The production compose file (docker-compose.prod.yml:1-2) still uses a single shared image:

x-app: &default-app
  image: ghcr.io/openradx/adit:latest

Analysis: This is actually fine because:

• Production uses a pre-built image from GHCR, not local builds
• No parallel building occurs in production deployment
• The race condition only affects local development with BuildKit

Note: No action needed, just confirming this is intentional.

---

🎯 Code Quality

• Style: Changes follow existing conventions ✓
• Formatting: YAML indentation is correct ✓
• Clarity: Image names are descriptive and match service names ✓

---

🔒 Security

No security concerns identified. The changes are limited to image naming and don't affect:

• Container permissions
• Network exposure
• Secret handling
• Dependencies

---

⚡ Performance

Positive Impact: The CI change is actually an improvement:

• Builds once instead of potentially building multiple times
• Uses Docker layer caching effectively
• Parallel service startup remains unaffected

---

🧪 Test Coverage

Observation: The PR doesn't add tests, but this is reasonable because:

• Changes are infrastructure/configuration only
• The CI workflow itself serves as integration test
• Docker Compose validation happens implicitly when CI runs

Suggestion: Consider manually testing locally that all four services start correctly with:

docker compose -f docker-compose.base.yml -f docker-compose.dev.yml up --build

---

📝 Recommendations Summary

1. Required: Address the init service image naming inconsistency
2. Recommended: Explain or revert the fail-fast removal
3. Optional: Add a comment in docker-compose.dev.yml explaining the per-service image naming strategy

---

Overall Assessment

The core fix is sound and solves a real problem. With the init service issue addressed, this PR will be ready to merge. Good work identifying and fixing the BuildKit race condition!

Would you like me to suggest specific code changes for the issues mentioned above?