Feature: Make devcontainer more developer friendly

[olivembo]

Currently the image is based on buildpack-deps. Developers are missing several tools, they need in their daily work.

Proposed approach

The image should be based on Ubuntu.

Tools as the following should be installed:

• ca-certificates
• curl
• gnupg
• lsb-release
• bazel
• python
• gdb
• git
• gh
• unzip
• zip
• devscripts
• iproute2
• jq
• sudo
• ....

Furthermore, in future we can create a lightweight developer container that is based on this one, where the host user is created in, and the things like .bashrc, .ssh are copied over.

Corresponds to this decision record:

https://github.com/eclipse-score/score/blob/main/docs/design_decisions/DR-003-infra.md

[lurtz]

It already has most of these tools installed. I am using the devcontainer as my main development environment in S-CORE. What I miss most at the moment is gdb, but lldb is available.

I am a bit confused about https://github.com/eclipse-score/score/blob/main/docs/design_decisions/DR-003-infra.md, because there was already this eclipse-score/score#1256

[olivembo]

It already has most of these tools installed. I am using the devcontainer as my main development environment in S-CORE. What I miss most at the moment is gdb, but lldb is available.

ok then gdb is set and will be accepted? I guess if the discussion continues we will "win" some more tools.

I am a bit confused about https://github.com/eclipse-score/score/blob/main/docs/design_decisions/DR-003-infra.md, because there was already this eclipse-score/score#1256

This was about having a devcontainer for development. The decision record about using the same in the pipelines, for consistency reasons ("Works on my machine").

[lurtz]

ok then gdb is set and will be accepted? I guess if the discussion continues we will "win" some more tools.

I see no argument against e.g. gdb. I already added rustfmt and other Rust tools to it: fe3588c

At the moment the container also contains GCC 13 and a Rust Compiler. Personally I would like if we start using that by default in S-CORE, however S-CORE prefers to use toolchain files via Bazel. Our stance (myself and @opajonk) is that it would be cool to support airgapped environments, which is currently not possible with S-CORE.

[opajonk]

Agreed, of course. The devcontainer should be (1) a devcontainer (common, reproducible environment for the developers) (2) a container for the CI (to simplify config management of "the environment", avoid any "works on my machine stuff" as much as possible, allow for air-gapped builds, etc. etc.). (2) is a debate, for sure - no worries, I know that. So, take this as "my opinion".

Currently, I am personally working on a 1.0.0 of the devcontainer as it is, i.e. make it really stable (current main has issues building, for example), and make it work reliably also for arm64. Adding more tools if they are required for day-to-day work I have no issue with - but we have to watch the container size as well. That is all.

[FScholPer]

I only have the requirement that I can build all we have with the devcontainer ideally with a working debugging setup. I would say please start a proposal