DR-001-Infra: Integration Strategy for External Development Tools #1687
Conversation
|
The created documentation from the pull request is available at: docu-html |
There was a problem hiding this comment.
Pull Request Overview
This PR replaces a placeholder RST file with a comprehensive Markdown design document that outlines the integration strategy for external development tools. The document establishes standards for tool distribution, version pinning, and execution consistency across different environments.
- Converts format from RST to Markdown while expanding content significantly
- Documents a multi-pronged approach using devcontainers, Bazel aspects, and native installs
- Categorizes tools by their integration requirements and optimal distribution methods
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| docs/design_decisions/DR-001-infra.rst | Removes placeholder RST file with basic copyright header |
| docs/design_decisions/DR-001-infra.md | Adds comprehensive design document detailing tool integration strategy with requirements, options analysis, and implementation approach |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| 2. **Config Consistency**: Central baseline config; explicit, reviewable local overrides with drift detection. | ||
| 3. **Performance**: Fast full and incremental runs; leverage remote cache/execution for heavy, Bazel-config-dependent tools. | ||
| 4. **Offline & Retention**: Prefetch & store artifacts for ≥10 years; fully offline execution path. | ||
| 5. **Platforms**: Ubuntu x86_64 + additional to be defined, e.g. Alpine, arm64 etc. |
There was a problem hiding this comment.
This should refer to the platform definition document once it is established. This may or may not happen before this PR is complete ;-)
There was a problem hiding this comment.
Yeah sure! We can add a reference afterwards. But it's not critical for the decision here.
| ## 5. Conclusion | ||
|
|
||
| - **Devcontainer** is the primary distribution for all tools, ensuring consistency and ease of onboarding. | ||
| - The same devcontainer (possibly stripped down) is used in CI for reproducibility. |
There was a problem hiding this comment.
| - The same devcontainer (possibly stripped down) is used in CI for reproducibility. | |
| - The same devcontainer (possibly stripped down) is used in CI for reproducibility. | |
| However, it must be ensured that the devcontainer strictly builds _on top_ of the CI container to avoid that CI issues cannot be reproduced locally. |
There was a problem hiding this comment.
I would like to pull details to the next level of detail, when we talk about how to implement this DR. I'll add this without explicitly specifying on top.
| - **Devcontainer** is the primary distribution for all tools, ensuring consistency and ease of onboarding. | ||
| - The same devcontainer (possibly stripped down) is used in CI for reproducibility. | ||
| - **Bazel aspects** are used for tools that benefit from Bazel-config-dependent analysis or caching. Custom Bazel rules are possible but not actively pursued. | ||
| - For small/fast CI jobs, **native installs** are preferred due to speed, especially when version pinning is less critical (see Deep Dive 4.3). |
There was a problem hiding this comment.
Could be, but I would first try containers. Maybe CI + devcontainer on top. One problem, one solution. Otherwise, I can already see the "oops we forgot to bump this tool here - that is why it broke!!" issues... after many hours of investigation.
There was a problem hiding this comment.
Versioning etc I would like to pull to the next level of detail, when we talk about how to implement this DR.
Rendered: https://eclipse-score.github.io/score/pr-1687/design_decisions/DR-001-infra.html