Skip to content

Minor changes Apple silicon dev #30

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
photocyte wants to merge 2 commits into from
Closed

Minor changes Apple silicon dev #30

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9805e01
Specify amd64 for dev-containers
photocyte Aug 13, 2025
324761e
ignore .DS_Store
photocyte Aug 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .devcontainer/docker-compose.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
services:
devcontainer:
platform: linux/amd64
Copy link

@coderabbitai coderabbitai bot Aug 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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 || true

Length 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-focal

Note: 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.

Suggested change
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.

Copy link
Author

@photocyte photocyte Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@coderabbitai coderabbitai bot Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@ejfine ejfine Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Separately, can you have github build a Codespace off your current branch and confirm that's still functional?

Copy link
Contributor

@ejfine ejfine Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

anytime we're messing around with the guts of the devcontainer configuration, it's good to ensure it's still compatible with Github Codespaces

build:
context: .
args:
Expand Down
4 changes: 4 additions & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -76,4 +76,8 @@ dist
*.log
**/logs/log*.txt

# macOS dev cleanliness
*.DS_Store
.DS_Store

# Ignores specific to this repository