Initial Eclipse S-CORE Development Container

[opajonk]

This PR introduces a pre-built devcontainer with all features required by eclipse-score/score#1256

In detail, that means:

• All tools required to build all aspects of Eclipse S-Core (code, tests, documentation, ...), both in CI and locally. The container was tested with baselibs, communication, inc_feo.
• A convenient development environment based on Microsoft Visual Studio Code (even though the container can be used separately, and with other development environments, of course).
• Pinned versions of all tools, so that tool-updates are container updates, which can be introduced fully automatic and tested via e.g. Dependabot to Eclipse S-Core.

The devcontainer itself is maintained and built using a (very simple) devcontainer. All build scripts can be executed locally as well as in CI. See README for details on that.

Closes eclipse-score/score#1256

[opajonk]

This likely needs an update. Please suggest how this should look like.

[MaximilianSoerenPollak]

CODEOWNERS are the people that are required to approve a PR before it can be merged.

In this repository, it seems you two are the main protagonists, so for me this seems fine.

[lurtz]

I suppose the code matches https://github.com/Elektrobit/eclipse-score_devkit/tree/8120c0e961b99213921afd6c0a57cd4085ff54a3

[opajonk]

This will need an update. We need a secret which is allowed to publish to the image registry.

[opajonk]

This will need an update. We need a secret which is allowed to publish to the image registry.

[lurtz]

When I test the .devcontainer at communication I get this error:

[2025-07-04T21:34:13.296Z] {"errors":[{"code":"DENIED","message":"requested access to the resource is denied"}]}
.
[2025-07-04T21:34:13.479Z] [httpOci] 403: Failed to fetch bearer token for 'ghcr.io': {"errors":[{"code":"DENIED","message":"requested access to the resource is denied"}]}
[2025-07-04T21:34:13.479Z] [httpOci] ERR: Failed to fetch Bearer token from registry.
[2025-07-04T21:34:13.479Z] Request 'https://ghcr.io/v2/eclipse-score/devcontainer/manifests/latest' failed
[2025-07-04T21:34:13.858Z] [httpOci] 403: Credentials for 'ghcr.io' may be expired. Attempting request anonymously.
[2025-07-04T21:34:13.858Z] {"errors":[{"code":"DENIED","message":"requested access to the resource is denied"}]}
.
[2025-07-04T21:34:14.045Z] [httpOci] 403: Failed to fetch bearer token for 'ghcr.io': {"errors":[{"code":"DENIED","message":"requested access to the resource is denied"}]}
[2025-07-04T21:34:14.045Z] [httpOci] ERR: Failed to fetch Bearer token from registry.
[2025-07-04T21:34:14.045Z] Request 'https://ghcr.io/v2/eclipse-score/devcontainer/manifests/latest' failed
[2025-07-04T21:34:14.045Z] Error fetching image details: No manifest found for ghcr.io/eclipse-score/devcontainer:latest.
[2025-07-04T21:34:14.046Z] Start: Run: docker pull ghcr.io/eclipse-score/devcontainer:latest
[2025-07-04T21:34:14.485Z] Error response from daemon: Head "https://ghcr.io/v2/eclipse-score/devcontainer/manifests/latest": denied
[2025-07-04T21:34:14.488Z] Stop (442 ms): Run: docker pull ghcr.io/eclipse-score/devcontainer:latest

Is this expected?

This is the used config

{
    "name": "eclipse-s-core",
    "image": "ghcr.io/eclipse-score/devcontainer:latest",
    "initializeCommand": "mkdir -p ${localEnv:HOME}/.cache/bazel"
}

[opajonk]

Yes that will work only after the merge. The CI did not run in S-CORE context yet.

[opajonk]

Force pushed last iteration. Things are complete finally. I missed one thing, that still had to be fixed.

[MaximilianSoerenPollak]

Me personally would never force pre-commit anything.

But if this helps your workflow & you want this in your repository, seems fine by me.

[opajonk]

I would recommend this, yes. We have made very good experience with "strict automated checks, but open to changes". What I mean is: don't "overdocument" and "overchecklist" - rather have an automation do it. This is cheap and can handle really a lot of issues. But: be open if people have doubts about settings. It should be always possible to discuss and give arguments why things are set like they are.

[MaximilianSoerenPollak]

We might need the 'codelens' extension here too, as Esbonio does not seem great with publishing / showing the errors.

But this could be added if needed (based on user feedback)

[opajonk]

Absolutely. I consider this container the 1.0.0 - "works on the known use-cases" (which was to me: "run bazel build" or whatever bazel commands were documented; e.g. for FEO I also tried running the example). Adding / changing later is really "just a pull-request away" ;-)

[MaximilianSoerenPollak]

For me this looks fine, as far as I understand it.
Seems to be a rather thoroughly integrated feature, thanks for the hard work on this.

I think once there is users more requirements will come to light & adaptations can be made accordingly.