Minor changes Apple silicon dev#30
Minor changes Apple silicon dev#30photocyte wants to merge 2 commits intoLabAutomationAndScreening:mainfrom
Conversation
Relevant error: docker pull mcr.microsoft.com/devcontainers/universal:2.13.1-focal 2.13.1-focal: Pulling from devcontainers/universal no matching manifest for linux/arm64/v8 in the manifest list entries
WalkthroughUpdates devcontainer configuration to target linux/amd64 and extends .gitignore with macOS-specific DS_Store exclusions. No code, runtime, build, or test logic changed. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.gitignore (1)
79-82: Deduplicate DS_Store ignores; one pattern is sufficient.Both patterns match the same files; keeping one is cleaner. Optionally ignore AppleDouble resource forks too.
# macOS dev cleanliness -*.DS_Store .DS_Store +# Optionally also ignore AppleDouble resource forks +# ._*
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these settings in your CodeRabbit configuration.
📒 Files selected for processing (2)
.devcontainer/docker-compose.yml(1 hunks).gitignore(1 hunks)
| @@ -1,5 +1,6 @@ | |||
| services: | |||
| devcontainer: | |||
| platform: linux/amd64 | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Pinning platform to linux/amd64 may cause build/run platform mismatches; make it overridable and verify Dockerfile honors TARGETPLATFORM.
On Apple Silicon this fixes devcontainers by forcing x86 emulation, but when the service is built locally (build: context: .), Compose can error if the built image is arm64 while the service requests amd64. Suggest making the platform opt-in via env var (keeps your default) and ensure the Dockerfile uses ARG TARGETPLATFORM or FROM --platform to build the correct arch.
Apply this small improvement so developers can override without editing the file:
- platform: linux/amd64
+ platform: ${DEVCONTAINER_PLATFORM:-linux/amd64}To verify your build path won’t mismatch, run this in the repo to check Dockerfiles for platform-awareness:
🏁 Script executed:
#!/bin/bash
# Look for Dockerfiles and check for TARGETPLATFORM/BUILDPLATFORM hints
fd -HI -t f -g 'Dockerfile*' | while read -r f; do
echo "=== $f ==="
rg -n --color=never -e '^\s*FROM(\s+--platform=\S+)?\s' -e '\bARG\s+(TARGETPLATFORM|BUILDPLATFORM)\b' "$f" || true
done
# Also check for devcontainer.json that may set runArgs/compose files
fd -HI -t f -g 'devcontainer.json' | xargs -I{} sh -c 'echo "=== {} ==="; cat "{}"' 2>/dev/null || trueLength of output: 3272
Make devcontainer platform configurable and remove the hard amd64 pin in the Dockerfile
I ran the check — .devcontainer/Dockerfile contains a hard pin (line 4: FROM --platform=linux/amd64) and devcontainer.json uses docker-compose.yml. Please make these changes so the platform can be overridden and the Dockerfile honors TARGETPLATFORM.
Files to change
- .devcontainer/docker-compose.yml — make platform overridable
- .devcontainer/Dockerfile — stop hard-pinning platform; use ARG TARGETPLATFORM
Suggested diffs
For .devcontainer/docker-compose.yml:
- platform: linux/amd64
+ platform: ${DEVCONTAINER_PLATFORM:-linux/amd64}For .devcontainer/Dockerfile (replace the pinned FROM):
-FROM --platform=linux/amd64 mcr.microsoft.com/devcontainers/universal:2.13.1-focal
+ARG TARGETPLATFORM=linux/amd64
+FROM --platform=$TARGETPLATFORM mcr.microsoft.com/devcontainers/universal:2.13.1-focalNote: using ARG in FROM requires BuildKit / recent Docker; if you cannot rely on that, consider removing the --platform flag from the Dockerfile and controlling platform via the compose env var instead.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| platform: linux/amd64 | |
| platform: ${DEVCONTAINER_PLATFORM:-linux/amd64} |
🤖 Prompt for AI Agents
.devcontainer/docker-compose.yml around line 3 and .devcontainer/Dockerfile
(replace the pinned FROM at line 4): the compose file currently hard-codes
platform: linux/amd64 — make it overridable by replacing the literal with an
environment variable (e.g. use a ${PLATFORM:-linux/amd64} or
${TARGETPLATFORM:-linux/amd64} substitution so callers can set the platform),
and in the Dockerfile remove the hard --platform=linux/amd64 pin and either (a)
use an ARG TARGETPLATFORM and change the FROM to reference it via FROM
--platform=${TARGETPLATFORM} <image> (requires BuildKit/recent Docker), or (b)
simply drop the --platform flag and let docker-compose supply the platform via
the env variable; ensure devcontainer.json/composition passes the chosen
variable through.
There was a problem hiding this comment.
I don't think this is the right solution, given that the development platform has to match the deployment platform, and the deployment platform is infrastructure as code elsewhere.
There was a problem hiding this comment.
@photocyte That's a valid point about maintaining dev/prod parity - it's definitely important to avoid environment drift that could cause deployment issues.
To better understand the context: is your deployment platform definitively amd64/x86_64? If so, then keeping the hard-coded platform: linux/amd64 makes sense for consistency.
The original issue was helping Apple Silicon developers get started with dev-containers. If maintaining the amd64 platform is the right approach for your infrastructure, then your solution addresses that need while preserving the deployment alignment you mentioned.
I'll note that this approach means Apple Silicon developers will run under emulation, which works but may have some performance implications during development. However, if that tradeoff is acceptable for maintaining environment consistency, then your approach is sound.
| @@ -1,5 +1,6 @@ | |||
| services: | |||
| devcontainer: | |||
| platform: linux/amd64 | |||
There was a problem hiding this comment.
Separately, can you have github build a Codespace off your current branch and confirm that's still functional?
There was a problem hiding this comment.
anytime we're messing around with the guts of the devcontainer configuration, it's good to ensure it's still compatible with Github Codespaces
## Link to Issue or Message thread LabAutomationAndScreening/cloud-courier#30 ## Why is this change necessary? People are encountering issues when developing on Mac either on baremetal or using devcontainers on Apple Silicon ## How does this change address the issue? Specifies amd64 more explicitly, and adds some mac-specific things to .gitignore ## What side effects does this change have? None ## How is this change tested? Building a codespace and a devcontainer with these new settings ## Other Ignores some more log files and bumps some pulumi depenedencies
|
Closing in preference to #32 |
Addressing the issue raised in #30 by pulling in upstream template changes from LabAutomationAndScreening/copier-base-template#80 and LabAutomationAndScreening/copier-python-package-template#59
2 participants
Link to Issue or Message thread
(No explicit issue, describing issue below)
Why is this change necessary?
Makes it easier to onboard devs using Docker Desktop on Apple Silicon devices (even when using the dev-containers).
How does this change address the issue?
Was a necesarry change in my hands to get started with the dev-container .
What side effects does this change have?
There may be subtleties with how it intersects with cloud deployment targets (in other repos?), if the deployment targets do not use amd64 platform. I think amd64 is a reasonable explicit default for cloud deployment, because I'd assume it's 99% of available cloud resources even with the impressive efficiency advantages of arm cloud resources.
How is this change tested?
I haven't tested this change beyond my 1st pass through.
Other
Feedback on any cleanliness from commit messages to PR, always good!
Summary by CodeRabbit