docs: add DR-003-infra for devcontainer strategy

[olivembo]

Summary

This PR adds Design Decision Record DR-003-infra that outlines the strategy for standardizing S-CORE development environments using devcontainers.

Changes

• Added docs/design_decisions/DR-003-infra.md with comprehensive analysis of devcontainer approaches
• Proposes hybrid approach with base container + service-specific extensions
• Addresses both local development experience and CI/CD performance needs

Key Decisions

• Base devcontainer: Shared tooling foundation for consistency
• Service extensions: Rich local development environments
• CI/CD optimization: Lean containers for performance
• Layered approach: Balance between simplicity and flexibility

Benefits

• Consistent development environment across contributors
• Improved onboarding experience
• Optimized CI/CD performance
• Flexible local development workflows
• Clear separation of concerns

This addresses the infrastructure standardization efforts and provides a clear path forward for S-CORE development environment consistency.

Testing

• Document follows existing DR format and structure
• All requirements and options clearly documented
• Decision rationale provided with clear consequences
• Next steps defined for implementation

[github-actions]

The created documentation from the pull request is available at: docu-html

[Copilot]

Pull Request Overview

This PR introduces a comprehensive Design Decision Record (DR-003-infra) that establishes a standardized devcontainer strategy for S-CORE development environments. The document addresses the challenge of providing consistent, efficient development environments that work well both locally and in CI/CD pipelines.

• Proposes a hybrid approach using a base devcontainer with optional service-specific extensions
• Balances developer experience needs with CI/CD performance requirements
• Establishes clear guidelines for container layering and usage patterns

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[nick-hildebrant-etas]

It's not really in the scope of this document, but as a door for layer local side effects, maybe it should be mentioned that additional layers should not be required for CI/CD. The CI layer is wholly responsible for builds and required tooling, which should be brought in via Bazel whenever possible?

[opajonk]

I agree with the general "Hybrid Approach" idea. However, I would suggest to use a base layer (built in the devcontainer repository), which contains all tools that also CI requires.

If there are then tools which are required only for development of certain repositories, and which really add a significant amount of data (!! I would not do this for just a few MB, since it adds overhead and complexity !!), we can create (or re-use existing) devcontainer features.

An example can be seen in the devcontainer repository itself. The devcontainer.json there constructs the local devcontainer (used for developing the s-core devcontainer) from "default" building blocks:

• javascript-node:0-18 acts as base image
• ghcr.io/devcontainers/features/git etc. are additional "layers"
• These additional layers are then on-the-fly added on top of the base image.

However, we must keep in mind:

• Everything that is downloaded from "the internet" may stop existing at any point in time, killing our development environment and builds. We already had this, with the downtime of the Arm GitLab.
• Everything that is downloaded from "the internet" may be used for injecting "unwanted things" into the supply chain. This applies to dynamic features, but also for Bazel, its modules and additional files, Visual Studio Code plugins, etc. It is much less risky to use/audit/archive pre-built images, than an on-the-fly created development & build environment. Food for thought...

[FScholPer]

@olivembo Is that something you want to drive forward?

[olivembo]

I agree with the general "Hybrid Approach" idea. However, I would suggest to use a base layer (built in the devcontainer repository), which contains all tools that also CI requires.

If there are then tools which are required only for development of certain repositories, and which really add a significant amount of data (!! I would not do this for just a few MB, since it adds overhead and complexity !!), we can create (or re-use existing) devcontainer features.

An example can be seen in the devcontainer repository itself. The devcontainer.json there constructs the local devcontainer (used for developing the s-core devcontainer) from "default" building blocks:

* `javascript-node:0-18` acts as base image

* `ghcr.io/devcontainers/features/git` etc. are additional "layers"

* These additional layers are then on-the-fly added on top of the base image.

However, we must keep in mind:

* Everything that is downloaded from "the internet" may stop existing _at any point in time_, killing our development environment and builds. We already had this, with the downtime of the Arm GitLab.

* Everything that is downloaded from "the internet" may be used for injecting "unwanted things" into the supply chain. This applies to dynamic features, but also for Bazel, its modules and additional files, Visual Studio Code plugins, etc. It is _much less risky_ to use/audit/archive pre-built images, than an on-the-fly created development & build environment. Food for thought...

I just adapted the DR-003 document. Agree to the points.

The "downloaded from the internet" problem, you have imho in any case. Maybe in the dynamic features more than with the usage of prebuild images, but that should be treated independent of this DR.

[dcalavrezo-qorix]

In terms of storage, the free GH runners provide approx. 14 GB of space. We're currently on the verge on maxing that out for some repos. Not sure what will happen after introducing containerized builds in CI.

[olivembo]

@olivembo Is that something you want to drive forward?

We would drive it from ETAS side