-
Notifications
You must be signed in to change notification settings - Fork 18
test with priviledge #251
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.
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
Draft
acefsan
wants to merge
9
commits into
master
Choose a base branch
from
acefsan/setup-minikube
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
test with priviledge #251
Conversation
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
…cript The previous Dockerfile failed to build on Ubuntu 24.04 (Noble) because pip3 install is blocked by PEP 668 externally-managed-environment protection. This prevents system-wide pip installs to protect the OS Python environment. Changed the uv installation to use the official uv installer script which downloads the standalone binary, consistent with how other tools (kubectl, minikube, skaffold, helm) are installed in this Dockerfile. Error that was occurring: error: externally-managed-environment × This environment is externally managed 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
The uv installer script installs to $HOME/.local/bin (not /root/.cargo/bin) because the linuxserver/code-server base image sets HOME=/config. This caused the build to fail with: mv: cannot stat '/root/.cargo/bin/uv': No such file or directory Fixed by using $HOME/.local/bin path and also moving uvx binary. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
This adds a container initialization script that dynamically detects the Docker socket GID and adds the abc user to the correct group at container startup. This ensures Docker access works regardless of the host's Docker group GID. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Simplified Docker group setup by using the same pattern as
jupyter-docker: setting `user: "abc:${DOCKER_GID}"` in
docker-compose.yaml. This eliminates the need for a custom
initialization script.
The DOCKER_GID is passed from the host environment and sets
the abc user's primary group to match the Docker socket GID
at container startup.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
Removed SUDO_PASSWORD environment variable, sudo-passwordless.sh
script, and its invocation from postCreateCommand. Sudo access is
not required for the core functionality since:
- Docker access is handled via user: "abc:${DOCKER_GID}"
- All tools are pre-installed in the Dockerfile
- Minikube runs with docker driver without needing sudo
This simplifies the configuration. Can be added back if needed.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
This command runs on the host before docker-compose starts and creates
a .env file with DOCKER_GID set to the host's Docker group GID. This
allows docker-compose.yaml to use ${DOCKER_GID} in the user field to
give the abc user proper Docker socket access.
Matches the pattern used in workbench-jupyter-docker.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
Reverted from using `user: "abc:${DOCKER_GID}"` in docker-compose.yaml
back to the init script approach. The user field was bypassing the
linuxserver/code-server init system, which prevented proper /config
directory ownership setup.
This approach:
- Lets the container start normally with linuxserver init system
- Init scripts properly set up abc user and /config ownership
- Our docker-setup.sh script runs as part of init to add abc to docker group
- Matches the pattern used by the base vscode app
The workbench-jupyter-docker uses the user field successfully because
their pre-built image already has /home/jupyter owned by jupyter.
Our base image doesn't pre-create /config ownership.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.