Skip to content

Make the Docker image runnable out of the box - #64

Open
satoshi-kimura wants to merge 3 commits into
abulmo:masterfrom
satoshi-kimura:master
Open

Make the Docker image runnable out of the box#64
satoshi-kimura wants to merge 3 commits into
abulmo:masterfrom
satoshi-kimura:master

Conversation

@satoshi-kimura

Copy link
Copy Markdown

Summary

This PR updates the sample Docker setup so Edax can be built and run directly from the image.

Previously, the Docker instructions required several manual steps after docker run, including building Edax inside the container, downloading the evaluation data, extracting it, and launching the binary manually.

With this change, the Docker image becomes runnable out of the box:

docker build . -t edax
docker run --rm -it edax

Changes

  • update the Docker base image from gcc:4.9 to gcc:13-bookworm
  • install required tools for the documented Docker workflow:
    • make
    • clang
    • curl
    • p7zip-full
  • build Edax during docker build
  • download and extract the evaluation data during image build
  • add an entrypoint so the container starts Edax directly
  • simplify the README Docker instructions accordingly
  • remove the unused problem files from the Docker image
  • restore the original # simple sample comment in the Dockerfile

Why

The previous Docker setup no longer worked as documented:

  • the old base image was outdated
  • the documented workflow depended on tools that were not installed in the image
  • the container was not directly runnable and required several manual steps after startup

This PR keeps the Dockerfile as a simple sample, while making the documented Docker flow reproducible and immediately usable.

Result

After this change, users can start Edax with:

docker build . -t edax
docker run --rm -it edax

Notes

  • the Docker image now includes only the files needed to build and run Edax interactively
  • the problem directory was excluded because it contains solver problem data and is not required for normal interactive play

@qodo-code-review

Copy link
Copy Markdown

Review Summary by Qodo

Make Docker image runnable out of the box

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Update Docker base image from gcc:4.9 to gcc:13-bookworm
• Build Edax and download evaluation data during image build
• Add entrypoint to make container directly runnable
• Simplify Docker workflow to single docker run command
• Install required build tools (make, clang, curl, p7zip-full)
Diagram
flowchart LR
  A["Old Dockerfile<br/>gcc:4.9"] -->|Update base image| B["New Dockerfile<br/>gcc:13-bookworm"]
  B -->|Install tools| C["Build environment<br/>make, clang, curl, p7zip"]
  C -->|Build Edax| D["Compiled binary<br/>lEdax"]
  C -->|Download & extract| E["Evaluation data<br/>eval.7z"]
  D -->|Set entrypoint| F["Runnable container<br/>docker run edax"]
  E -->|Set entrypoint| F
  G["Old README<br/>Manual steps"] -->|Simplify| H["New README<br/>Two commands"]
Loading

Grey Divider

File Changes

1. Dockerfile ✨ Enhancement +30/-3

Complete Docker image build automation

• Update base image from gcc:4.9 to gcc:13-bookworm for modern toolchain
• Install additional dependencies (clang, curl) and optimize apt layer
• Copy source code and LICENSE into image
• Add architecture detection logic to support x86-64-v3 and armv8.5-a
• Build Edax with clang compiler during image build
• Download and extract evaluation data (eval.7z) automatically
• Create entrypoint script to launch Edax directly on container start

Dockerfile


2. README.md 📝 Documentation +1/-12

Simplify Docker usage documentation

• Remove manual build steps from Docker instructions
• Remove manual evaluation data download and extraction steps
• Simplify Docker workflow to two commands: build and run
• Replace volume mount with built-in binary execution
• Remove architecture-specific binary path references

README.md


Grey Divider

Qodo Logo

@qodo-code-review

qodo-code-review Bot commented Mar 17, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0)

Grey Divider


Action required

1. Too-new CPU target 🐞 Bug ⛯ Reliability
Description
The Dockerfile forces ARCH to x86-64-v3 / armv8.5-a, which compiles with -march for those
ISAs and can crash at runtime on older CPUs that lack those instruction sets. This breaks the goal
of being runnable out-of-the-box on typical x86_64/arm64 hosts.
Code

Dockerfile[R21-22]

+      x86_64|amd64) EDAX_ARCH='x86-64-v3' ;; \
+      aarch64|arm64) EDAX_ARCH='armv8.5-a' ;; \
Evidence
The image hard-codes modern micro-architecture targets, and the build system passes the selected
ARCH directly to -march, making the produced binary require those CPU features at runtime.

Dockerfile[19-22]
src/Makefile[59-60]
src/Makefile[131-137]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Docker image currently compiles Edax with `-march=x86-64-v3` on amd64 and `-march=armv8.5-a` on arm64. These targets can produce binaries that crash with illegal-instruction on older CPUs.

## Issue Context
The Makefile passes `ARCH` directly into `-march=$(ARCH)`, so the chosen `EDAX_ARCH` becomes a hard runtime requirement.

## Fix Focus Areas
- Dockerfile[19-26]

## Suggested approach
- Change defaults to broadly compatible baselines:
 - amd64: `x86-64` (or at most `x86-64-v2`)
 - arm64: `armv8-a`
- Add `ARG EDAX_ARCH` so advanced users can opt into `x86-64-v3`, `x86-64-v4`, `armv8.5-a`, etc.
- Use `EDAX_ARCH=&quot;${EDAX_ARCH:-&lt;default&gt;}&quot;` after selecting a platform default, so overrides work cleanly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Unverified eval download 🐞 Bug ⛨ Security
Description
The Docker build downloads and extracts eval.7z without any checksum/signature verification,
allowing a tampered or corrupted artifact to be baked into the produced image. This is a
supply-chain security risk and can also make builds non-reproducible.
Code

Dockerfile[R28-29]

+    curl -fL -o eval.7z https://github.com/abulmo/edax-reversi/releases/download/v4.4/eval.7z; \
+    7z x -y eval.7z; \
Evidence
The Dockerfile performs a network download and extraction step but does not verify
integrity/authenticity of the downloaded content before unpacking it into the image.

Dockerfile[28-30]
Best Practice: SLSA supply-chain + Dockerfile hardening best practices

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The image build downloads `eval.7z` and extracts it without validating integrity/authenticity.

## Issue Context
Any compromise of the download path (or upstream asset replacement) can inject unexpected content into the image.

## Fix Focus Areas
- Dockerfile[28-30]

## Suggested approach
- Add a pinned checksum and verify before extraction, e.g.:
 - `ARG EVAL_SHA256=&lt;known&gt;`
 - `echo &quot;$EVAL_SHA256  eval.7z&quot; | sha256sum -c -`
- (Optional) Prefer signature verification if the project publishes signed checksums/releases.
- Fail the build if verification fails.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

3. Wrong arch under buildx 🐞 Bug ⛯ Reliability
Description
The Dockerfile uses uname -m to select the build ARCH, which can differ from the intended target
architecture when using docker buildx --platform, producing a non-runnable image for the target
platform. This can break CI/CD multi-arch builds and remote builders.
Code

Dockerfile[R19-23]

+    arch="$(uname -m)"; \
+    case "$arch" in \
+      x86_64|amd64) EDAX_ARCH='x86-64-v3' ;; \
+      aarch64|arm64) EDAX_ARCH='armv8.5-a' ;; \
+      *) echo "Unsupported architecture: $arch" >&2; exit 1 ;; \
Evidence
uname -m reflects the build container environment, not the declared Docker target platform; the
Dockerfile doesn’t use standard BuildKit-provided target platform variables to make this selection
stable under cross-builds.

Dockerfile[19-23]
Best Practice: Docker BuildKit multi-platform builds

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Using `uname -m` for architecture detection can select the wrong target when building with `docker buildx --platform`, resulting in a binary for the wrong architecture.

## Issue Context
BuildKit provides standard build arguments (`TARGETARCH`, `TARGETPLATFORM`) specifically for this use case.

## Fix Focus Areas
- Dockerfile[17-26]

## Suggested approach
- Add:
 - `ARG TARGETARCH`
 - `ARG EDAX_ARCH`
- If `EDAX_ARCH` is not explicitly set, map `TARGETARCH`:
 - `amd64` -&gt; `x86-64` (or your chosen default)
 - `arm64` -&gt; `armv8-a`
- Remove `uname -m` logic to make builds deterministic under `--platform`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

Comment thread Dockerfile
Comment on lines +21 to +22
x86_64|amd64) EDAX_ARCH='x86-64-v3' ;; \
aarch64|arm64) EDAX_ARCH='armv8.5-a' ;; \

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Too-new cpu target 🐞 Bug ⛯ Reliability

The Dockerfile forces ARCH to x86-64-v3 / armv8.5-a, which compiles with -march for those
ISAs and can crash at runtime on older CPUs that lack those instruction sets. This breaks the goal
of being runnable out-of-the-box on typical x86_64/arm64 hosts.
Agent Prompt
## Issue description
The Docker image currently compiles Edax with `-march=x86-64-v3` on amd64 and `-march=armv8.5-a` on arm64. These targets can produce binaries that crash with illegal-instruction on older CPUs.

## Issue Context
The Makefile passes `ARCH` directly into `-march=$(ARCH)`, so the chosen `EDAX_ARCH` becomes a hard runtime requirement.

## Fix Focus Areas
- Dockerfile[19-26]

## Suggested approach
- Change defaults to broadly compatible baselines:
  - amd64: `x86-64` (or at most `x86-64-v2`)
  - arm64: `armv8-a`
- Add `ARG EDAX_ARCH` so advanced users can opt into `x86-64-v3`, `x86-64-v4`, `armv8.5-a`, etc.
- Use `EDAX_ARCH="${EDAX_ARCH:-<default>}"` after selecting a platform default, so overrides work cleanly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread Dockerfile
Comment on lines +28 to +29
curl -fL -o eval.7z https://github.com/abulmo/edax-reversi/releases/download/v4.4/eval.7z; \
7z x -y eval.7z; \

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Unverified eval download 🐞 Bug ⛨ Security

The Docker build downloads and extracts eval.7z without any checksum/signature verification,
allowing a tampered or corrupted artifact to be baked into the produced image. This is a
supply-chain security risk and can also make builds non-reproducible.
Agent Prompt
## Issue description
The image build downloads `eval.7z` and extracts it without validating integrity/authenticity.

## Issue Context
Any compromise of the download path (or upstream asset replacement) can inject unexpected content into the image.

## Fix Focus Areas
- Dockerfile[28-30]

## Suggested approach
- Add a pinned checksum and verify before extraction, e.g.:
  - `ARG EVAL_SHA256=<known>`
  - `echo "$EVAL_SHA256  eval.7z" | sha256sum -c -`
- (Optional) Prefer signature verification if the project publishes signed checksums/releases.
- Fail the build if verification fails.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant