setup devcontainer

[AlexanderLanin]

🧱 Devcontainer Setup for Unified Development Environment

🎯 Goal

Provide a consistent development environment via Devcontainers to reduce onboarding friction and tooling issues across contributors. This image will be used by all SCORE-related repositories (dozens in total), so it must be robust, reusable, and actively maintained.

---

✅ Current Situation

We currently require a number of tools to be installed in addition to Bazel. This includes Python, Graphviz, Bazelisk, and shell autocompletion for Bazel. These tools are not always easy to install correctly across different systems, especially for new contributors.

---

🚀 Solution

Implement a reusable Devcontainer setup based on a Docker image that includes all required tools preinstalled. The image should be published to GitHub Container Registry (GHCR) and referenced via .devcontainer/devcontainer.json or .devcontainer.json in consuming repositories.

Target image name: ghcr.io/eclipse-score/devcontainer

The base image should include:

• Based on an extended Ubuntu image, quite certainly:
  • mcr.microsoft.com/devcontainers/python:1.2-3.12
• Preinstalled tools:
  • Python (needed for Bazel formatting bug workaround)
  • Graphviz
  • Bazelisk (with current bazel version pre-downloaded)
  • Shell autocompletion for Bazel

---

🛠️ Concrete Tasks

• Create a new GitHub repository (name: eclipse-score/devcontainer)
• Create a Dockerfile that installs all required tools
• Add GitHub Actions workflow to:
  • Build the image
  • Optional: Tag it with semantic version (e.g. v1.0.0) and latest
  • Push to GHCR under ghcr.io/eclipse-score/devcontainer
• Optional: Add typical metadata to the container
• Use the image from GHCR in .devcontainer/devcontainer.json or .devcontainer.json in at least one repo (e.g. score)
• Verify that all tools are functional inside the container
• Optional: Add documentation (README.md) to eclipse-score/devcontainer

---

🔄 Considered Alternatives

Some tools could theoretically be installed via Bazel, but this was previously evaluated and rejected due to high implementation and maintenance cost. We chose to use system-level tools with clear documentation instead.

---

🧠 Notes

• The image will become the base for all development work across the SCORE ecosystem
• Keep it generic, stable, and easy to extend.
• This devcontainer will remain entirely optional, it's just meant to ease the pain of installing all the required tools.

---

📚 References

• Example: eclipse-score/score/.devcontainer
• Docs: Development Environment Setup

[opajonk]

This looks quite interesting, I will take a look!

[opajonk]

I think I will have a first iteration of a devcontainer ready rather soon. We should then discuss if that is the right thing and how to proceed. I will update this ticket with comments.

[AlexanderLanin]

@opajonk looking at your draft you should consider starting with mcr.microsoft.com/devcontainers/python:1.2-3.12 instead if raw ubuntu

[opajonk]

I checked also mcr.microsoft.com/devcontainers/python:1.2-3.12. However, that one is based on Debian instead of Ubuntu. A few of the tools have packages which are created for specific Ubuntu releases only. Also, I'd argue that Ubuntu is more often used in "commercial contexts". S-CORE is Open Source, of course, but the primary usage is commercial. Hence, using a commercially supported OS has advantages.

[AlexanderLanin]

Fine with me, so far I'm workin in that container, but I don't care which one it is, as long as it's working :-)

IMHO mcr.microsoft.com/devcontainers/base:ubuntu would make sense then.

Beyond git, this image / Dockerfile includes zsh, Oh My Zsh!, a non-root vscode user with sudo access, and a set of common dependencies for development.

It's not a lot. But it's not nothing. You could also use the features directly instead: https://github.com/devcontainers/images/blob/main/src/base-ubuntu/.devcontainer/devcontainer.json