Conversation
FoniksFox
changed the title
There was a problem hiding this comment.
Pull request overview
Adds a VS Code Dev Containers configuration intended to enable STM32 development/debugging inside a container using the hyperloop-firmware-toolchain image with USB passthrough.
Changes:
- Added
.devcontainer/devcontainer.jsonto define the devcontainer build, runtime args (USB access), VS Code extensions, and startup command. - Added
.devcontainer/Containerfileto build the devcontainer from the toolchain base image.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
.devcontainer/devcontainer.json |
Defines devcontainer runtime settings (USB access, user settings) and VS Code extensions for embedded/CMake workflows. |
.devcontainer/Containerfile |
Base image + workspace working directory for the devcontainer. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| "-v", "/dev/bus/usb:/dev/bus/usb", | ||
| "--userns=keep-id" | ||
| ], | ||
| "postStartCommand": "stlink-server &", |
There was a problem hiding this comment.
Starting stlink-server via postStartCommand with & can lead to orphaned/duplicated servers on rebuild/reopen and may not stay running depending on how the devcontainer shell is launched. Consider managing it more explicitly (e.g., check if it’s already running before starting, or use a dedicated supervisor/service script).
| "postStartCommand": "stlink-server &", | |
| "postStartCommand": "sh -lc 'pgrep -x stlink-server >/dev/null || nohup stlink-server >/tmp/stlink-server.log 2>&1 &'", |
| @@ -0,0 +1,3 @@ | |||
| FROM ghcr.io/hyperloop-upv/hyperloop-firmware-toolchain:latest | |||
There was a problem hiding this comment.
Using the :latest tag makes the devcontainer environment non-reproducible and can break unexpectedly when the image is updated. Consider pinning to a specific version tag or immutable digest (and updating deliberately when needed).
| FROM ghcr.io/hyperloop-upv/hyperloop-firmware-toolchain:latest | |
| FROM ghcr.io/hyperloop-upv/hyperloop-firmware-toolchain@sha256:REPLACE_WITH_APPROVED_IMAGE_DIGEST |
| }, | ||
| "workspaceFolder": "/workspaces/${localWorkspaceFolderBasename}", | ||
| "runArgs": [ | ||
| "--privileged", |
There was a problem hiding this comment.
--privileged grants the container essentially full access to the host. If USB access is the main requirement, consider a more constrained configuration (e.g., --device=/dev/bus/usb and/or specific cgroup device rules) to reduce the security blast radius.
| "--privileged", |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Just what the title says, use hyperloop-firmware-toolchain image for a devcontainer with usb access to be able to debug from inside the container. Doesn´t really work with the hyperloop-firmware-toolchain image right now, it depends on the new image that would be made from the new ST-LIB dockerfile. It can be tried out by just copying that dockerfile in the .devcontainer/Containerfile here.