[Infrastructure]: Make Docker smoke faster and less dependent on package downloads

[morning-verlu]

Context

The Docker trial path is important for first-time visitors who do not want local Java/Gradle or Codespaces.

Current command:

./scripts/docker-smoke.sh

It builds the image, runs kaios tour, validates the generated capsule, replays it offline, and validates the bundled Evidence Sample.

Current problem

In this local environment, the full smoke repeatedly stalls on external Docker/Alpine package downloads rather than on KAI OS itself.

Observed on June 16, 2026:

• Dockerfile based on alpine:3.20 progressed through Alpine package installation but spent a long time downloading/installing openjdk17-jre-headless and was interrupted before completion.
• A trial change to amazoncorretto:17-alpine avoided installing OpenJDK through apk, but first-time Docker Hub layer download for the 147MB base image was also too slow in this environment and was not kept.
• docker build --check . passes, but full ./scripts/docker-smoke.sh remains unverified locally because of external download speed.

Goal

Make the Docker path more reliable for first-time evaluators.

Possible directions:

• publish a prebuilt Docker image for releases.
• use a multi-stage or prebuilt Java base image only after verifying multi-arch pulls are reliable.
• add a smoke mode that skips image build when a release image already exists locally.
• document a faster fallback when Docker Hub or Alpine mirrors are slow.

Acceptance

• ./scripts/docker-smoke.sh can complete in a normal network environment.
• The chosen path works on arm64 and amd64.
• README / INSTALL / VERIFY docs reflect the verified Docker path.
• The launch checklist can remove the Docker caveat only after full smoke passes.

[morning-verlu]

Docker smoke reliability update on main:

Implemented in commit 223fa2e:

• Switched Dockerfile from alpine:3.20 + apk add openjdk17-jre-headless to bellsoft/liberica-openjre-alpine:17, so the image starts from a prebuilt Java 17 runtime.
• Kept only small Alpine packages in apk add: ca-certificates, curl, git, and unzip.
• Added ./scripts/docker-smoke.sh --no-build / --skip-build plus KAIOS_DOCKER_BUILD=0 so an existing image can be reused for repeated smoke checks.
• Added --image and --workdir options, with workdir normalized to an absolute path before Docker volume mounts.
• Updated README, START_HERE, INSTALL, and VERIFY docs with the no-build smoke path.

Verification completed:

bash -n scripts/docker-smoke.sh
./scripts/docker-smoke.sh --help
docker build --check .
docker manifest inspect bellsoft/liberica-openjre-alpine:17
git diff --check

The bellsoft/liberica-openjre-alpine:17 manifest includes both linux/amd64 and linux/arm64.

Full smoke status: still not fully verified in this local network. I attempted ./scripts/docker-smoke.sh, but Docker Hub layer download remained extremely slow; the second attempt reached about 6.29MB / 38.94MB on the base layer after several minutes before I stopped it. This is still an improvement over the old Dockerfile because KAI OS no longer waits on Alpine OpenJDK package installation, but the acceptance item requiring a full smoke pass on a normal network remains open.

I am leaving this issue open until someone can run ./scripts/docker-smoke.sh end to end on a normal network and report PASS.

[morning-verlu]

Follow-up in commit dbe62ea:

Added a lightweight Docker preflight mode for slow Docker Hub environments:

./scripts/docker-smoke.sh --preflight

What it checks without building the full image:

• Dockerfile syntax/build checks via docker build --check .
• the base image declared in Dockerfile
• base image manifest includes Linux amd64 and Linux arm64

Verified locally:

./scripts/docker-smoke.sh --preflight
bash -n scripts/docker-smoke.sh
./scripts/docker-smoke.sh --help
git diff --check

Local result:

kaios docker preflight ok
base_image: bellsoft/liberica-openjre-alpine:17

Docs updated in README, START_HERE, INSTALL, VERIFY, and Contributor Board. Full Docker smoke is still the acceptance gate for closing this issue, but contributors now have a fast preflight command to run before attempting the heavy layer download.