chore: add devcontainer contributor workflow [DX-822]

[Tyler Collins (t-col)]

This repository still relied on a legacy CI setup and did not have a checked-in devcontainer, which meant contributors had to reconstruct the right toolchain locally and had no guarantee that their machine matched the environment used in automation. The practical effect is that routine fixes and feature work are harder to start, and environment drift becomes a source of avoidable failure.

This change makes the repository-local devcontainer the source of truth for both local development and CI. It adds .devcontainer/Dockerfile and .devcontainer/devcontainer.json, adds a GitHub Actions workflow built around devcontainers/ci, removes the retired CircleCI or Travis build configuration, and updates the public contributor documentation and badges so the documented path matches the checked-in tooling. CodeQL is left in place.

For the Java repos, this also switches the devcontainer to a multi-arch Temurin JDK 8 base so Apple Silicon machines can run the environment natively instead of through x86 emulation.

Validation for this repo was done against the checked-in devcontainer configuration rather than a hand-built local environment. Built the devcontainer and ran ./mvnw -B -q -DskipTests dependency:go-offline && ./mvnw -B test. I also rechecked the updated devcontainer JSON and workflow YAML for validity and confirmed that stale CircleCI/Travis references were removed from the public README and CONTRIBUTING entry points.

[wiz-inc-38d59fb8d7]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	-
Secrets	-
IaC Misconfigurations	1  3
SAST Findings	-
Software Management Findings	-
Total	1  3

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

[ethan ozelius (ethan-ozelius-contentful)]

Just out of curiosity, why are the apt-get command different across different dev containers? This repo goes as far as setting up a new group/user, is that specific to the java implementation?

https://github.com/contentful/contentful.rb/pull/274/changes & https://github.com/contentful/contentful-management.rb/pull/278/changes

• Does not make any apt-get updates/installations

https://github.com/contentful/contentful.net/pull/394/changes

RUN apt-get update \
    && export DEBIAN_FRONTEND=noninteractive \
    && apt-get install -y --no-install-recommends \
        curl \
        git \
        openssh-client \
    && rm -rf /var/lib/apt/lists/*

[Tyler Collins (t-col)]

Good question - that's a consequence of the base image choice, not something Maven or the Java SDK itself specifically needed.

I used that one because Mircrosoft doesn't publish a Java 8 version of the base devcontainer image. That one I needed to use instead is pretty minimal, and unlike the richer Microsoft devcontainer images, it does not already give us (1) a vscode user, and (2) common contributor tools like curl, git, and openssh-client.

That’s why the Dockerfile sets those things up by itself.