-
Notifications
You must be signed in to change notification settings - Fork 674
Add Dev Container setup for streamlining local development on Linux #8861
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
base: main
Are you sure you want to change the base?
Conversation
with Dockerfile, build scripts, and caching setup
before adding ubuntu user to sudoers file
to builder stage in devcontainer docker image
to improve git remote support
as GitHub CLI is being installed via apt already
to Dockerfile for configurable build type
caching cmake setup and make steps as seperate layers
as this setup isn't used for CI yet that could seed it's docker cache
by installing cmake for use of ctest
as .dockerignore ignores .git folder to uneccesary cache busting which interfear in expected use of SlicerMacroExtractRepositoryInfo
and correct working dir for xvfb-run ctest comand
to simplify docker build bake DX for user shorting the both CLI comand invocation and avoid altering default context setting
As copying files 7.11GB from overlay takes too long for now.
|
Thanks for working on this, it seems quite promising 👍 I'm not really familiar with this approach. Would it allow us to have debug builds of the latest Slicer as images that could quickly start up, for example in a github codespace, to allow debugging of C++ code quickly and efficiently? Are there examples of big projects like Slicer that provide Dev Containers so we can see how it works in practice? |
as the severs for Ubuntu's snapshot repo have been slow recently
to emulate a Codespace runtime on a GitHub VM
to prevent nagging warning from display manager that ships with devcontainers feature desktop-lite
Yep, we could extend the GitHub Actions to build and host pre-built debug images that could then be pulled into Codespaces for remote browser based development workflows. For example, in 88aca1c I patched the config from I use for locally on my linux workstation, to what would be available from the remotely on the VM hosting a user's GitHub Codespace. Here I use a noVNC feature with VSCode port forwarding for display forwarding GUIs:
simplescreenrecorder-2025-11-20_16.26.58.mp4
I've developed setups like this before for FOSS and commercial projects, some examples:
Slicer/.devcontainer/README.md Lines 129 to 130 in b423044
Additionally, pattern searching across github may help to find more popular example: |
This reverts commit 88aca1c.
|
It sounds very useful. I'll be curious to hear what others think about this. @lassoan @sam @ebrahimebrahim @jcfr |
|
It would be great to discuss this a bit at a weekly meeting |
This pull request introduces a comprehensive Dev Container setup for the project, enabling reproducible development and build environments using Docker and BuildKit. It adds multi-stage Dockerfile instructions, configuration files for caching and environment, a detailed README for onboarding, and scripts for initializing the container. The changes are designed to streamline building, testing, and packaging workflows, and to support advanced development scenarios such as hardware acceleration and debugging.
Dev Container Infrastructure
.devcontainer/Dockerfilethat defines separate stages for building, testing, packaging, and running Slicer, with extensive use of BuildKit cache mounts and environment configuration for efficient development..devcontainer/devcontainer.jsonto configure the Dev Container environment, including image selection, runtime arguments for hardware and debugging, workspace mounts, environment variables, and recommended extensions.Developer Experience
.devcontainer/README.mdwith step-by-step instructions for setting up Docker, Git LFS, NVIDIA toolkit, and development tools, as well as guidance for building, running, and launching the Dev Container using CLI, VSCode, CodeSpaces, etc.