feat: add multi-arch Docker image build to release pipeline

[stack72]

Build and push linux/amd64 and linux/arm64 Docker images to DockerHub
(systeminit/swamp) on each release, using pre-compiled binaries from
the GitHub Release. Based on denoland/deno for Deno runtime support.

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com

[github-actions]

Code Review

No blocking issues found. This PR adds Docker image building to the release pipeline with a minimal Dockerfile. No TypeScript source changes, so CLAUDE.md conventions around tests, license headers, and libswamp imports are not applicable.

Suggestions

1. Pin the Deno base image version in the Dockerfile — FROM denoland/deno:latest means builds are not reproducible across time. Consider pinning to a specific version (e.g., denoland/deno:2.2.2) or at least a major version tag, and updating it deliberately.

2. Pass the version from the release job via outputs instead of using gh release view — While the concurrency group prevents parallel workflow runs, gh release view returns the repo's latest release, which could theoretically be a manually-created release. Passing the version/tag as a job output from release to docker would be more robust:

   # In the release job:
   outputs:
     version: ${{ steps.version.outputs.version }}
   # In the docker job, reference:
   needs.release.outputs.version

3. Consider adding a latest tag — Many Docker users expect a latest tag alongside versioned tags. Could be added to the manifest creation step.

4. Consider running as non-root — The Dockerfile runs as root by default. Adding a USER directive would follow container security best practices, though this depends on whether swamp needs root-level access at runtime.

5. RUN chmod +x is redundant — The workflow already runs chmod +x on the binary before the Docker build context is created (line 192). The COPY instruction preserves file permissions, so the RUN chmod +x in the Dockerfile is unnecessary (though harmless).

[github-actions]

CI Security Review

Critical / High

None.

Medium

1. Unpinned Docker actions (release.yml:196-227): docker/setup-qemu-action@v3, docker/setup-buildx-action@v3, docker/login-action@v3, and docker/build-push-action@v6 are pinned to tags, not commit SHAs. Notably docker/login-action handles Docker Hub credentials — a compromised tag could exfiltrate DOCKERHUB_TOKEN. However, this is consistent with the existing repo pattern (e.g., softprops/action-gh-release@v2, peter-evans/repository-dispatch@v3), so flagging as advisory only. Fix: Pin to full commit SHAs.

2. Unpinned base image in Dockerfile (Dockerfile:1): FROM denoland/deno:latest means every build pulls whatever is currently tagged latest. A compromised or breaking upstream image affects all future builds. Fix: Pin to a specific version or digest, e.g., FROM denoland/deno:2.2.2 or use a @sha256:... digest.

Low

1. ${{ env.docker_tag }} interpolated in run: block (release.yml:231-234): The docker_tag value is derived from a tag this workflow created (date-based format), so exploitation risk is negligible. Using shell variable expansion ("${docker_tag}") instead of Actions expression syntax in run: blocks would be marginally safer as a general practice.

Verdict

PASS — No critical or high severity findings. The new docker job is well-structured: it uses needs: release to sequence correctly, narrows permissions to contents: read at job level, checks out ref: main (not PR head), and secrets are scoped appropriately. The medium findings are supply-chain hygiene improvements worth addressing but do not block merge.