Accepted
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]).
- Add
.devcontainer/Dockerfileand.devcontainer/devcontainer.jsonusing the Eclipse Temurin JDK 8 base image (multi-arch: supports both x86_64 and arm64). - The Dockerfile sets up a
vscodeuser and installscurl,git, andopenssh-client(not provided by the minimal Temurin base). postCreateCommandpre-fetches Maven dependencies offline:./mvnw -B -q -DskipTests dependency:go-offline.- GitHub Actions CI (
ci.yml) runs tests inside the devcontainer viadevcontainer exec— the exact same container contributors use locally. - Remove stale CircleCI / Travis CI configuration.
- 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 usesdevcontainers/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.javaextension is auto-installed in the devcontainer for IDE support.