Menu
Procedures for building and smoke-testing a vscode-devcontainer Dockerfile locally. Use when validating a new or modified Dockerfile before release.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Looks up the latest stable release for a single software package and returns the exact version string to pin in a Dockerfile. Use when you have a dependency name, its current version, and its source type (go-module, npm-package, github-release, maven-central, debian-snapshot) and need the correct new version string. Do not use for packages marked as unpinned or intentionally @latest.
Verifies a dependency update for supply chain attack indicators before applying version changes. Checks package ownership, release authenticity, known vulnerabilities, and suspicious patterns.
Conventions and patterns for writing Dockerfiles in this repository. Use when creating a new Dockerfile or adding software to an existing one.
Reads one or more Dockerfiles and produces a structured catalog of every pinned dependency version, grouped by source type (go-module, npm-package, github-release, maven-central, debian-snapshot). Use when preparing a version-update workflow, auditing dependency freshness, or identifying which packages in a Dockerfile need a version bump.
| name | dockerfile-test |
| description | Procedures for building and smoke-testing a vscode-devcontainer Dockerfile locally. Use when validating a new or modified Dockerfile before release. |
Steps for locally building a Dockerfile and verifying that the resulting image works correctly.
Read the Dockerfile path supplied by the caller. If none is given, find the most recently created version directory:
find vscode-devcontainer/versions -name "Dockerfile" | sort | tail -1
Run docker build with --progress=plain to show full output. For the vscode-devcontainer image, the build context is the directory containing the Dockerfile:
docker build --progress=plain \
-t devcontainer-test:local \
vscode-devcontainer/versions/<tag>/
To test a specific platform explicitly:
docker build --progress=plain --platform linux/amd64 \
-t devcontainer-test:local \
vscode-devcontainer/versions/<tag>/
Report the full build log. If the build fails, show the last 50 lines of output and stop — do not proceed to smoke testing.
From the Dockerfile, identify the key binaries that should be present in the final image. Focus on:
Example canary set:
| Binary | Source Type |
|---|---|
go version | Go SDK (COPY from go-sdk stage) |
dlv version | Go tool (go install) |
golangci-lint --version | Go tool (go install) |
node --version | Node.js (apt/nodesource) |
flyway -v | Maven Central |
gh --version | GitHub CLI (custom apt) |
aws --version | AWS CLI (custom installer) |
docker --version | Docker (custom apt) |
buf --version | Go tool |
gitleaks version | GitHub Release binary |
Run each binary with a version flag inside the image:
docker run --rm devcontainer-test:local go version
docker run --rm devcontainer-test:local dlv version
docker run --rm devcontainer-test:local golangci-lint --version
docker run --rm devcontainer-test:local node --version
docker run --rm devcontainer-test:local flyway -v
docker run --rm devcontainer-test:local gh --version
docker run --rm devcontainer-test:local aws --version
docker run --rm devcontainer-test:local docker --version
docker run --rm devcontainer-test:local buf --version
docker run --rm devcontainer-test:local gitleaks version
For each command, record: pass / fail and the output line.
If any binary is missing (command not found) or exits non-zero, report the error and investigate the Dockerfile for the root cause.
Produce a summary table:
| Binary | Expected Version | Actual Output | Status |
|---|---|---|---|
| go | 1.26.2 | go version go1.26.2 linux/amd64 | PASS |
| dlv | v1.26.2 | Delve Debugger Version: 1.26.2 | PASS |
| ... | ... | ... | ... |
Highlight any failures and recommend fixes.
Multi-stage COPY failure: If a Go binary is missing in the final image, check that the go install step succeeded in tool-builder and that COPY --from=tool-builder /go/bin /go/bin is present in the final stage.
Architecture mismatch: If building on Apple Silicon (arm64) and a binary is missing or crashes, try building explicitly with --platform linux/arm64. If a binary is only available for amd64, check the Dockerfile's architecture fallback logic.
docker: command not found inside container: The Docker CLI is installed but the daemon socket is not mounted inside the container — this is expected. Only test with docker --version, not with docker ps or docker run.
flyway -v exits non-zero: Flyway may print to stderr and exit 1 without a database connection. Treat any output containing the version number as a pass.