ci: validate Dockerfile on PRs via source-check build - #344
ci: validate Dockerfile on PRs via source-check build#344manzuoni-astera wants to merge 1 commit into
Conversation
The full image build-and-push (checkpoints + all pixi envs) only runs on main/tags in docker.yml, so a broken Dockerfile — a bad COPY path, a dropped env in the hardcoded `pixi install -e` list, a broken pixi bootstrap — isn't caught until after merge. Add a paths-filtered workflow that builds the Dockerfile's existing `source-check` stage (base + source COPY only; no checkpoint pull, no env installs, no push) on PRs touching Dockerfile*, pyproject.toml, pixi.lock, or the wrapper scripts.
📝 WalkthroughWalkthroughAdds a GitHub Actions workflow that validates the Dockerfile’s ChangesDocker validation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Adds a lightweight GitHub Actions workflow to validate the repository’s main Dockerfile during PRs (and selected pushes) by building the existing source-check stage. This is intended to catch Dockerfile regressions (e.g., bad COPY paths / broken bootstrap) before merge without doing the full “checkpoints + all pixi envs + push” build.
Changes:
- Introduces
.github/workflows/docker-validate.ymlwithpaths:filtering for Docker-related and pixi metadata changes. - Builds the
Dockerfilesource-checktarget usingdocker/build-push-actionwith Buildx and GHA caching. - Adds concurrency controls to avoid redundant runs per ref.
Comments suppressed due to low confidence (1)
.github/workflows/docker-validate.yml:32
- Same as above:
pull_request.pathsincludesDockerfile.astera, but the job doesn't build/validate it (only buildsDockerfiletargetsource-check). Either remove it from the filter or add a separate check that can validateDockerfile.astera.
- 'Dockerfile'
- 'Dockerfile.astera'
- 'docker-entrypoint.sh'
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| permissions: | ||
| contents: read | ||
|
|
||
| steps: | ||
| - name: Checkout code | ||
| uses: actions/checkout@v4 | ||
| with: | ||
| persist-credentials: false | ||
|
|
||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 | ||
|
|
||
| - name: Build source-check stage | ||
| uses: docker/build-push-action@v6 | ||
| with: | ||
| context: . | ||
| file: Dockerfile | ||
| target: source-check | ||
| push: false | ||
| cache-from: type=gha | ||
| cache-to: type=gha,mode=max |
| - 'Dockerfile' | ||
| - 'Dockerfile.astera' | ||
| - 'docker-entrypoint.sh' | ||
| - 'pyproject.toml' |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/docker-validate.yml:
- Line 18: Remove the Dockerfile.astera path entry from both the on.push.paths
and on.pull_request.paths trigger lists in the Docker validation workflow,
leaving validation triggered only by paths exercised by the public Dockerfile
target.
- Around line 63-71: Update the docker/build-push-action step named “Build
source-check stage” to set pull: true, while preserving target: source-check and
the existing cache configuration.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 27c882d8-5f72-4c67-9f38-2638b56ce785
📒 Files selected for processing (1)
.github/workflows/docker-validate.yml
| branches: [main] | ||
| paths: | ||
| - 'Dockerfile' | ||
| - 'Dockerfile.astera' |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files .github/workflows || true
echo "== docker-validate workflow =="
if [ -f .github/workflows/docker-validate.yml ]; then
cat -n .github/workflows/docker-validate.yml
else
echo "missing"
fi
echo "== docker files in repo =="
git ls-files | grep -E '(^|/)Dockerfile\.' || true
echo "== search Dockerfile.astera references =="
rg -n "Dockerfile\.astera|astera|source-check|docker|buildenv" . --glob '!node_modules/**' --glob '!dist/**' --glob '!build/**' || trueRepository: diff-use/sampleworks
Length of output: 10605
Remove Dockerfile.astera from the Dockerfile validation paths.
When only Dockerfile.astera changes, this workflow still runs and builds the public Dockerfile target (file: Dockerfile), so Astera-only Dockerfile changes pass without exercising the overlay Dockerfile. Drop the Dockerfile.astera entries from both on.push.paths and on.pull_request.paths unless a separate workflow is added that can validate Dockerfile.astera’s published base image.
Proposed fix
- - 'Dockerfile.astera'Remove this entry from both trigger lists.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - 'Dockerfile.astera' |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/docker-validate.yml at line 18, Remove the
Dockerfile.astera path entry from both the on.push.paths and
on.pull_request.paths trigger lists in the Docker validation workflow, leaving
validation triggered only by paths exercised by the public Dockerfile target.
| - name: Build source-check stage | ||
| uses: docker/build-push-action@v6 | ||
| with: | ||
| context: . | ||
| file: Dockerfile | ||
| target: source-check | ||
| push: false | ||
| cache-from: type=gha | ||
| cache-to: type=gha,mode=max |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow excerpt =="
sed -n '1,120p' .github/workflows/docker-validate.yml
echo
echo "== search docker build flags =="
rg -n "uses: docker/build-push-action|pull:|build-push-action@v6|docker build" .github/workflows/docker-validate.yml Dockerfile 2>/dev/null || true
echo
echo "== relevant Dockerfile lines =="
sed -n '1,80p' DockerfileRepository: diff-use/sampleworks
Length of output: 5409
🌐 Web query:
docker/build-push-action v6 pull option default false cache-from cache-to base image
💡 Result:
In the docker/build-push-action v6 (and other versions), the pull input option defaults to false [1][2][3]. When set to true, this option instructs the action to always attempt to pull all referenced images (such as base images) before the build begins [1][2]. Regarding caching: 1. cache-from: This option is used to specify external cache sources for Buildx (e.g., type=gha, type=registry, or type=local) [4][5]. It tells the builder where to look for existing cache layers to reuse during the build process [4]. 2. cache-to: This option defines the destination where cache artifacts generated during the build should be exported [4]. 3. Interaction with Base Images: The pull option is distinct from caching mechanisms. If you rely on base images, the builder automatically pulls them if they are not present locally. If you want to ensure the latest base image is always used, you can set pull: true [1][2]. However, caching (via cache-from) specifically stores and retrieves intermediate layers produced by your Dockerfile instructions; it does not replace the need for the builder to resolve and pull the specified base image [4]. For optimal performance in CI/CD environments, it is standard practice to combine appropriate cache-from and cache-to configurations (such as type=gha) to persist layers across workflow runs [6][4].
Citations:
- 1: https://github.com/docker/build-push-action?tab=readme-ov-file
- 2: https://github.com/docker/build-push-action/blob/v6.12.0/README.md
- 3: https://github.com/docker/build-push-action/tree/v6.4.0
- 4: https://www.blacksmith.sh/blog/cache-is-king-a-guide-for-docker-layer-caching-in-github-actions
- 5: https://github.com/docker/build-push-action/blob/v5.2.0/action.yml
- 6: https://docs.docker.com/build/ci/github-actions/cache/
Force a base-image pull during validation.
docker/build-push-action defaults pull to false; with GHA cache enabled, a cached build can reuse prior os-base layers and skip checking the current digest-pinned BASE_IMAGE. Keep target: source-check and add pull: true.
Proposed fix
file: Dockerfile
target: source-check
+ pull: true
push: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Build source-check stage | |
| uses: docker/build-push-action@v6 | |
| with: | |
| context: . | |
| file: Dockerfile | |
| target: source-check | |
| push: false | |
| cache-from: type=gha | |
| cache-to: type=gha,mode=max | |
| - name: Build source-check stage | |
| uses: docker/build-push-action@v6 | |
| with: | |
| context: . | |
| file: Dockerfile | |
| target: source-check | |
| pull: true | |
| push: false | |
| cache-from: type=gha | |
| cache-to: type=gha,mode=max |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/docker-validate.yml around lines 63 - 71, Update the
docker/build-push-action step named “Build source-check stage” to set pull:
true, while preserving target: source-check and the existing cache
configuration.
What
A new paths-filtered workflow (
docker-validate.yml) that builds the Dockerfile's existingsource-checkstage on PRs — base image + sourceCOPYonly, no checkpoint pull, nopixi install -e <env>, no push.Why
Today the full image build (checkpoints + all pixi envs) only runs on
main/tags indocker.yml. A Dockerfile regression — a badCOPYpath, a dropped env in the hardcodedpixi install -e boltz/protenix/rf3/protpardelle/analysislist, a broken pixi bootstrap — isn't caught until after merge, when the heavy build fails. This validates the cheap-to-check parts pre-merge.Scoped (via
paths:) to changes inDockerfile*,docker-entrypoint.sh,pyproject.toml,pixi.lock,run_grid_search.py, and the wrapper scripts, so it doesn't run on ordinary source changes. Uses GHA layer cache; ~a few minutes warm.Not covered
Dockerfile.astera(the Astera overlay) needs a published base image to build, so it's not exercised here — a follow-up could add abuildx --checklint for it.Summary by CodeRabbit