fix(devcontainer): sync to python_template's zero-build config - #9
Open
blooop wants to merge 3 commits into
Open
fix(devcontainer): sync to python_template's zero-build config#9blooop wants to merge 3 commits into
blooop wants to merge 3 commits into
Conversation
The devcontainer now pulls ghcr.io/blooop/python_template/devcontainer:latest instead of building the image locally. - The duplicate claude-code `features` block is gone. The feature is baked into that image already (ci/devcontainer.json is what CI builds it from, and that declares ../claude-code), so declaring it here made the spec build a derived image on the first launch of every branch and reinstall what the pulled image already had. - `--network=host` is gone. A container per branch is the point of `dl`, and host networking undoes it: every port a dev server binds becomes a host port, so two branches collide on the first one they share. - The `~/.ssh` and `~/.config/gh` mounts are gone. `dl` supplies GH_TOKEN, and the gh mount never worked in the first place because gh keeps its token in the system keyring, so the mounted hosts.yml carried no oauth_token. - `name` moved to the end of the file. It is the only per-repo line here, and sitting next to the image block -- the block the template changes most -- it conflicted on every `pixi run update-from-template-repo`. The tree is byte-identical to blooop/python_template#170 apart from that name.
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Reviewer's GuideThe PR synchronizes the devcontainer with the template’s zero-build workflow by publishing a CI-built GHCR image, simplifying branch launch configuration, upgrading pixi-based Claude installation, and replacing individual Claude mounts with a shared read-write host configuration directory. Reviewers should focus on the CI image/launch-config relationship, feature path and build context correctness, and the deliberate security implications of exposing the entire host ~/.claude directory to containers. Sequence diagram for launching a branch container with shared Claude credentialssequenceDiagram
participant User
participant Launcher as dl
participant GHCR
participant Container
participant HostClaude as Host ~/.claude
User->>Launcher: launch branch
Launcher->>GHCR: pull devcontainer:latest
GHCR-->>Launcher: published image with claude-code
Launcher->>Container: start container with GH_TOKEN
Launcher->>Container: bind-mount ~/.claude
Container->>HostClaude: read and refresh Claude credentials
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
The earlier commit on this branch removed the ~/.config/gh bind mount and
justified it with the claim that the mount never worked -- that `gh` keeps its
token in the system keyring, so the mounted hosts.yml carries no oauth_token.
That claim is false on this machine. ~/.config/gh/hosts.yml carries a real
oauth_token, and in a running container using that mount, with GH_TOKEN and
GITHUB_TOKEN unset, `gh auth status` reports:
Logged in to github.com account blooop (/home/vscode/.config/gh/hosts.yml)
gh writes to a keyring only where one is available and falls back to the file
otherwise, so the keyring claim held for some environment but not this one, and
it got generalised into the config as if it always held.
Nothing broke under `dl`, which is why it went unnoticed: `dl` forwards
GH_TOKEN, devpod applies workspace env after the devcontainer's own, and the
env token wins wherever both are present. The entry paths that lost gh auth
they previously had are the non-`dl` ones -- a plain `devpod up`, and VS Code's
Reopen in Container. So the mount comes back.
The ~/.ssh removal is unaffected and stays removed. It was verified separately
in a live container: devpod forwards an ssh agent at a socket path of its own,
`ssh-add -l` lists the host key, and `git ls-remote` against a git@github.com:
origin succeeds with an empty ~/.ssh. The old hardcoded
SSH_AUTH_SOCK=/home/vscode/.ssh/agent.sock actively overrode that working
forwarded socket, so it stays gone too.
Owner
Author
|
Pushed a correction to this branch. The earlier commit removed the Nothing broke under The |
…rek-install Synced from blooop/python_template. The previous postCreateCommand ended in `pixi run prek-install`. This repo does not define that task, so `pixi run` exited 127, the lifecycle hook failed, and container creation failed outright -- the workspace never came up. Found by launching the container; neither JSON validation nor CI sees it. postCreateCommand now calls .devcontainer/post-create.sh, which runs the task only where it exists. The script also seeds known_hosts. devpod forwards an ssh agent, so the host's ~/.ssh does not need mounting -- but the agent carries authentication, not host identity, and on a fresh container the first git operation over an ssh remote died with "Host key verification failed". Interactive users can click through that; scripts, agents and in-container CI cannot.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The devcontainer now pulls ghcr.io/blooop/python_template/devcontainer:latest
instead of building the image locally.
featuresblock is gone. The feature is baked intothat image already (ci/devcontainer.json is what CI builds it from, and that
declares ../claude-code), so declaring it here made the spec build a derived
image on the first launch of every branch and reinstall what the pulled image
already had.
--network=hostis gone. A container per branch is the point ofdl, andhost networking undoes it: every port a dev server binds becomes a host port,
so two branches collide on the first one they share.
~/.sshand~/.config/ghmounts are gone.dlsupplies GH_TOKEN, andthe gh mount never worked in the first place because gh keeps its token in the
system keyring, so the mounted hosts.yml carried no oauth_token.
namemoved to the end of the file. It is the only per-repo line here, andsitting next to the image block -- the block the template changes most -- it
conflicted on every
pixi run update-from-template-repo.The tree is byte-identical to blooop/python_template#170 apart from that name.
Depends on blooop/python_template#170. The published image already exists and is
public, so this works before that merges.
🤖 Generated with Claude Code
Summary by Sourcery
Adopt the shared zero-build development image while improving branch isolation, Claude authentication, and repository initialization.
New Features:
Bug Fixes:
Enhancements:
CI:
Documentation:
Chores: