docs: add DR-003-infra for devcontainer strategy #1845
Conversation
|
The created documentation from the pull request is available at: docu-html |
795d847 to
30842f9
Compare
Add design decision record for hybrid devcontainer approach in S-CORE. Provides rationale, options, and next steps for standardizing development environments.
30842f9 to
fb7c972
Compare
There was a problem hiding this comment.
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.
|
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? |
There was a problem hiding this comment.
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-18acts as base imageghcr.io/devcontainers/features/gitetc. 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...
|
@olivembo Is that something you want to drive forward? |
Summary
This PR adds Design Decision Record DR-003-infra that outlines the strategy for standardizing S-CORE development environments using devcontainers.
Changes
docs/design_decisions/DR-003-infra.mdwith comprehensive analysis of devcontainer approachesKey Decisions
Benefits
This addresses the infrastructure standardization efforts and provides a clear path forward for S-CORE development environment consistency.
Testing