ci: validate Docker builds and tool installation

.github/workflows/ci.yml

@@ -20,7 +20,7 @@ jobs:
     env:
       CARGO_TERM_COLOR: always
     steps:
-      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4.3.1
+      - uses: actions/checkout@v4
         with:
           persist-credentials: false
           fetch-depth: 0

.github/workflows/docker.yml

@@ -0,0 +1,92 @@
+name: Docker checks
+
+on:
+  push:
+    branches: [main]
+    paths:
+      - 'docker/**'
+      - '.github/workflows/docker.yml'
+      - 'install.sh'
+      - '**/rust-toolchain.toml'
+      - '**/Cargo.toml'
+      - '**/Cargo.lock'
+      - '**/build.rs'
+      - 'build-utils/**'
+      - '.cargo/**'
+      - '!**/*.md'
+  pull_request:
+    paths:
+      - 'docker/**'
+      - '.github/workflows/docker.yml'
+      - 'install.sh'
+      - '**/rust-toolchain.toml'
+      - '**/Cargo.toml'
+      - '**/Cargo.lock'
+      - '**/build.rs'
+      - 'build-utils/**'
+      - '.cargo/**'
+      - '!**/*.md'
+  workflow_dispatch:
+    inputs:
+      full_pipeline:
+        description: Run the minimal offline pipeline after installation
+        type: boolean
+        default: false
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
+  cancel-in-progress: true
+
+permissions:
+  contents: read
+
+jobs:
+  docker-build-and-install:
+    runs-on: ubuntu-24.04
+    timeout-minutes: 30
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          persist-credentials: false
+      - name: Check Docker script syntax
+        run: bash -n docker/docker-build docker/docker-run
+      - name: Set up Buildx
+        uses: docker/setup-buildx-action@v4
+      - name: Build and load the image
+        uses: docker/build-push-action@v7
+        with:
+          context: ./docker
+          platforms: linux/amd64
+          tags: palm:ci
+          load: true
+          push: false
+          cache-from: type=gha,scope=palm-docker-amd64
+          cache-to: type=gha,mode=max,scope=palm-docker-amd64
+      - name: Check the container environment and install PALM
+        env:
+          FULL_PIPELINE: ${{ inputs.full_pipeline || false }}
+        run: |
+          docker run --rm -i \
+            --mount "type=bind,source=$GITHUB_WORKSPACE,target=/checkout,readonly" \
+            --env FULL_PIPELINE \
+            palm:ci bash -se <<'CONTAINER'
+          python3 --version
+          palm_toolchain=$(python3 -c 'import tomllib; print(tomllib.load(open("/checkout/rust-toolchain.toml", "rb"))["toolchain"]["channel"])')
+          rustup run "$palm_toolchain" rustc --version
+          rustup component list --toolchain "$palm_toolchain" --installed
+          cargo llvm-cov --version | grep -Fx 'cargo-llvm-cov 0.6.16'
+
+          palm_work=$(mktemp -d /tmp/palm-docker-check.XXXXXX)
+          cp -R /checkout/. "$palm_work/"
+          cd "$palm_work"
+          export CARGO_TARGET_DIR="$palm_work/target"
+          ./install.sh
+          cargo brinfo --help
+          cargo call-chain --help
+          focxt --help
+          utgen --help
+
+          if [[ "$FULL_PIPELINE" == "true" ]]; then
+            python3 scripts/check_minimal.py --bin-dir "$HOME/.cargo/bin"
+          fi
+          CONTAINER

README.md

@@ -94,6 +94,8 @@ Run `docker/docker-build` to prepare an image with the pinned analysis toolchain
 
 Run `docker/docker-run` to open a shell in the repository mounted at `/home/palm/palm`, then follow [Installation](#installation). The container is removed when the shell exits; files written in the mounted repository remain on the host. Use working copies of target crates as described above.
 
+The [Docker CI workflow](.github/workflows/docker.yml) checks image construction and tool installation when Docker or build-environment files change. Its manual `full_pipeline` option also runs the minimal offline pipeline inside the container; see [CI scope](docs/build-validation.md#ci-and-further-checks).
+
 ## Development checks
 
 From the repository root, using the pinned toolchain:

docs/build-validation.md

@@ -47,8 +47,12 @@ Model configuration is loaded only when generation or repair starts. See the [ru
 
 ## CI and Further Checks
 
-The [CI workflow](../.github/workflows/ci.yml) checks builds, ordinary tests, CLI entry points, installer syntax/help, and example metadata on Linux. It also runs the [minimal pipeline and related regressions](minimal-pipeline.md) and [Bytes analysis checks](bytes-analysis.md). Actual tool installation and Docker image validation are separate checks.
+The [native CI workflow](../.github/workflows/ci.yml) checks builds, ordinary tests, CLI entry points, installer syntax/help, and example metadata on Linux. It also runs the [minimal pipeline and related regressions](minimal-pipeline.md) and [Bytes analysis checks](bytes-analysis.md).
 
 Changes limited to READMEs and the documentation paths selected in the workflow receive a patch whitespace check. Other changes and manual workflow runs execute the full offline suite. A documentation-only CI result does not imply that Rust tests ran.
 
+The independent [Docker checks workflow](../.github/workflows/docker.yml) builds a Linux AMD64 image, checks its Python, compiler, and coverage tools, installs all four PALM tool packages, and checks their command entry points. It runs for changes to Docker files, toolchain files, Cargo manifests/lockfiles, build scripts, build-utils, root Cargo configuration, the installer, or its own workflow. Ordinary Rust logic and documentation changes do not trigger it. The image uses BuildKit's GitHub Actions layer cache and is loaded only into the runner's local Docker engine.
+
+To run the minimal offline pipeline in the container as well, select **Docker checks → Run workflow** in GitHub Actions and enable `full_pipeline`. This uses the installed tool binaries and fixed local responses. Docker checks run independently of native CI, have a 30-minute job limit, and cancel superseded runs for the same PR or branch.
+
 The offline checks use temporary target copies and local model responses. They cover the scenarios documented in each guide; they do not measure model quality, provide general crash recovery, or establish support for arbitrary Rust projects.