ci: expand image build matrix and align PR, push, and release workflows#244
ci: expand image build matrix and align PR, push, and release workflows#244
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b53e931a83
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| build-args: | | ||
| OS=${{ matrix.os }} | ||
| CUDA_VERSION=${{ matrix.cuda_version }} | ||
| OPTIX_VERSION=${{ matrix.optix_version }} |
There was a problem hiding this comment.
Pass Geant4 version when publishing develop images
The PR workflow now validates the CUDA 13 / Ubuntu 24.04 develop variant with geant4_version: 11.4.1, but this publish step does not pass GEANT4_VERSION, so Docker falls back to the Dockerfile default (11.3.2). As a result, the pushed cuda-13.0.2-.../devel images are built from a different dependency stack than the one exercised in PR CI, which can let regressions ship even when PR checks are green.
Useful? React with 👍 / 👎.
| OS=${{ matrix.os }} | ||
| CUDA_VERSION=${{ matrix.cuda_version }} | ||
| OPTIX_VERSION=${{ matrix.optix_version }} |
There was a problem hiding this comment.
Pin release image toolchain args explicitly
This release build now omits GEANT4_VERSION and CMAKE_VERSION, so versioned release tags are no longer tied to an explicit toolchain and instead drift with future Dockerfile default changes. It also creates an immediate matrix mismatch: PR release-smoke for the same CUDA/OS/OptiX tuple is configured with Geant4 11.4.1, while this release job will currently build with the default 11.3.2.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Pull request overview
Updates the container build GitHub Actions workflows to make build variants (OS/CUDA/OptiX/Geant4) explicit in PR testing and to standardize image tag structure across PR, branch-push, and release builds.
Changes:
- Expand the PR workflow into explicit build matrices for a release “smoke build” and develop “build+test” across multiple OS/CUDA/OptiX/Geant4 combinations.
- Update push/release tagging to include CUDA/OS/OptiX details and add CUDA-major short tags; add a
develalias for the default CUDA major on pushes. - Simplify the release workflow by removing explicit Geant4/CMake matrix/build-args (falling back to Dockerfile defaults).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| .github/workflows/build-pull-request.yaml | Adds explicit build variants, a release smoke build, and develop tests with variant-specific tags and caching. |
| .github/workflows/build-push.yaml | Switches from target-based tags to variant tags + CUDA-major short tags; adds devel alias tagging. |
| .github/workflows/release.yaml | Aligns release tags with the new variant-based scheme and removes Geant4/CMake build-args from the release job. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| cache-from: type=gha,scope=build-release-smoke-${{ matrix.os }}-cuda-${{ matrix.cuda_version }}-optix-${{ matrix.optix_version }}-geant4-${{ matrix.geant4_version }} | ||
| cache-to: type=gha,mode=max,scope=build-release-smoke-${{ matrix.os }}-cuda-${{ matrix.cuda_version }}-optix-${{ matrix.optix_version }}-geant4-${{ matrix.geant4_version }} |
There was a problem hiding this comment.
Using cache-from/cache-to: type=gha requires permissions: actions: write (and contents: read) for the workflow/job; otherwise cache export/import can fail. Also, for PRs from forks the token can’t be granted write perms, so consider guarding cache-to behind a non-fork condition (or skipping export on forks).
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
| tags: | | ||
| ghcr.io/${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }} | ||
| docker.io/${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }} | ||
| ghcr.io/${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }} | ||
| ghcr.io/${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG_SHORT }} | ||
| docker.io/${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }} | ||
| docker.io/${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG_SHORT }} | ||
| target: ${{ matrix.target }} |
There was a problem hiding this comment.
This workflow used to push simple tags like develop/latest (based on the target). With the new tagging, only variant tags plus cuda<major> are pushed, so :develop and :latest won’t be updated anymore. If anything consumes those tags, consider keeping them as additional alias tags (or updating consumers in the same PR).
00a088e to
a8968ce
Compare
This PR updates the container build workflows to use explicit build variants instead of relying on default Docker build arguments, and aligns image tagging across PR, push, and release jobs.
Why
Previously, the PR workflow only varied
target, so builds implicitly depended on Dockerfile defaults for OS, CUDA, and OptiX. This change makes the tested and published build variants explicit, improves tag clarity, and keeps the PR smoke and test jobs aligned with the supported image combinations.Notes