Skip to content

Latest commit

 

History

History
30 lines (19 loc) · 2 KB

File metadata and controls

30 lines (19 loc) · 2 KB

ADR-0006: Devcontainer as Single Source of Truth for Dev and CI

Status

Accepted

Context

Before DX-822, contributors had to reconstruct the correct toolchain locally with no guarantee their environment matched CI. This caused environment drift and made routine contributions harder to start. The project previously used CircleCI / Travis CI without a checked-in devcontainer.

Apple Silicon (M1/M2/M3) machines could not run x86 JDK 8 images natively — they required emulation, which was slow and unreliable. Microsoft does not publish a Java 8 variant of their devcontainer base image, requiring a custom Dockerfile.

Reference: PR #209 (chore: add devcontainer contributor workflow [DX-822]).

Decision

  • Add .devcontainer/Dockerfile and .devcontainer/devcontainer.json using the Eclipse Temurin JDK 8 base image (multi-arch: supports both x86_64 and arm64).
  • The Dockerfile sets up a vscode user and installs curl, git, and openssh-client (not provided by the minimal Temurin base).
  • postCreateCommand pre-fetches Maven dependencies offline: ./mvnw -B -q -DskipTests dependency:go-offline.
  • GitHub Actions CI (ci.yml) runs tests inside the devcontainer via devcontainer exec — the exact same container contributors use locally.
  • Remove stale CircleCI / Travis CI configuration.

Consequences

  • Enables: Full environment parity between local dev and CI; Apple Silicon contributors can run the environment natively without emulation.
  • Requires: Docker and the Dev Container CLI (npm install -g @devcontainers/cli) for local use; GitHub Actions uses devcontainers/ci.
  • Trade-off: CI now requires a Docker build step, adding some overhead vs. a direct JDK setup. The parity benefit outweighs the cost.
  • VS Code: redhat.java extension is auto-installed in the devcontainer for IDE support.