Deduplicate and extend nightly/weekly workflows. - #11074
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe reusable workflow centralizes matrix construction, platform dispatch, result verification, failure reporting, and optional Slack alerts. Custom, nightly, and weekly workflows now invoke this shared workflow. ChangesCI matrix execution
Suggested reviewers: Merge Risk: 🟡 Moderate · up to This PR centralizes CI matrix execution and adds alternate-branch dispatch, but verification can still fail on forks or private mirrors because it runs without the artifact produced by skipped build jobs. Caller permissions may also prevent intended dispatch behavior, and the workflow broadens secret inheritance while using a mutable checkout reference. Merge should wait for the verification guard and an explicit permission decision. Comment |
![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
🧹 Nitpick comments (3)
.github/workflows/ci-matrix-build.yml (2)
83-83: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valuesuggestion: consolidate the four near-identical dispatch jobs.
dispatch-groups-linux-two-stage,dispatch-groups-windows-two-stage,dispatch-groups-linux-standalone, anddispatch-groups-windows-standalonediffer only in the matrix key, the called workflow, and the input name (pc-arrayvsjob-array). GitHub Actions cannot parameterizeuses:by matrix value, so full deduplication is not possible today. Keep the structure, but note thatfromJSON(...)['linux_two_stage']['keys']is repeated three times per job; a singleneeds.build-workflow.outputsper-platform key output would reduce the repeated parsing.Also applies to: 91-91, 94-94
61-61: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winSecurity Misconfiguration (CWE-829): Inclusion of Functionality from Untrusted Control Sphere
Reachability: Internal · Exploitability: Difficult
suggestion: Pin all three
actions/checkoutuses to full commit SHAs and retain version comments. The current@v6tag is mutable.Source: Path instructions
.github/workflows/ci-workflow-custom.yml (1)
40-41: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valuesuggestion: add the branch input to the concurrency key.
The group is
${{ github.workflow }}-on-${{ github.event_name }}-from-${{ github.ref_name }}. Two dispatches from the same ref with differentbranchvalues share one group. Withoutcancel-in-progress, the second run queues behind the first full matrix. Includeinputs.branchso independent matrix branches run in parallel.concurrency: - group: ${{ github.workflow }}-on-${{ github.event_name }}-from-${{ github.ref_name }} + group: ${{ github.workflow }}-on-${{ github.event_name }}-from-${{ github.ref_name }}-matrix-${{ inputs.branch }}
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 02db8b0f-3261-409e-8db0-9140bf0003ff
📒 Files selected for processing (4)
.github/workflows/ci-matrix-build.yml.github/workflows/ci-workflow-custom.yml.github/workflows/ci-workflow-nightly.yml.github/workflows/ci-workflow-weekly.yml
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review.
|
|
||
| verify-workflow: | ||
| name: Verify and summarize workflow results | ||
| if: ${{ always() && !cancelled() }} |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
#!/bin/bash
# Confirm the artifact download in workflow-results has no failure tolerance,
# and check how other workflows in the repo gate result-verification jobs.
fd -t f 'action.yml' .github/actions/workflow-results --exec sed -n '1,60p'
rg -n -B4 -A6 'workflow-results' .github/workflows
rg -n "github.repository == " .github/workflowsRepository: NVIDIA/cccl
Length of output: 8536
🏁 Script executed:
#!/bin/bash
set -e
printf '%s\n' '--- repository conventions and learnings ---'
find /tmp/coderabbit-repo-knowledge/nvidia-cccl-2f773195 -maxdepth 2 -type f -print
printf '%s\n' '--- workflow structure ---'
sed -n '1,180p' .github/workflows/ci-matrix-build.yml
printf '%s\n' '--- result verification job context ---'
sed -n '130,175p' .github/workflows/ci-matrix-build.yml
printf '%s\n' '--- workflow-results action ---'
sed -n '1,55p' .github/actions/workflow-results/action.ymlRepository: NVIDIA/cccl
Length of output: 16752
🏁 Script executed:
#!/bin/bash
set -e
printf '%s\n' '--- workflow conventions ---'
cat /tmp/coderabbit-repo-knowledge/nvidia-cccl-2f773195/conventions/github-workflows.md
printf '%s\n' '--- CI learnings relevant to this workflow ---'
cat /tmp/coderabbit-repo-knowledge/nvidia-cccl-2f773195/learnings/ci.mdRepository: NVIDIA/cccl
Length of output: 1191
🌐 Web query:
GitHub Actions actions/download-artifact behavior when the named artifact does not exist, and github.repository context in reusable workflow workflow_call
💡 Result:
When using the actions/download-artifact action, the behavior depends on whether a specific artifact name is provided [1][2]. If you specify a name, the action will attempt to find and download that specific artifact [3]. If the artifact does not exist, the action will throw an error and fail the workflow run (e.g., "Artifact 'name' not found") [3][4][5]. If you do not specify a name, the action attempts to download all artifacts for the workflow run [1][2]. As of version 4 of the action, if no artifacts are found, the action will also throw an error and fail the workflow run [6]. This is a departure from earlier versions (v3 and below), which would simply log that no artifacts were found and finish successfully [6]. Regarding the github.repository context in a reusable workflow: Within a reusable workflow triggered by workflow_call, the github.repository context refers to the repository that is calling (or triggering) the workflow, not the repository where the reusable workflow file itself resides [7]. If you need to reference the repository where the reusable workflow is defined, you can use the github.action_repository context instead [7]. This is particularly important when performing cross-repo operations, such as checking out code or accessing files located in the reusable workflow's own repository [8][7].
Citations:
- 1: https://github.com/actions/download-artifact
- 2: https://github.com/actions/download-artifact/blob/3f40cd641f8c4a2b41aaba3d9fc97a3cbae1992d/README.md
- 3: https://github.com/actions/download-artifact/blob/d3f86a10/src/download-artifact.ts
- 4: GitHub issue 250 in actions/download-artifact (link omitted to avoid creating a cross-reference)
- 5: GitHub issue 351 in actions/download-artifact (link omitted to avoid creating a cross-reference)
- 6: GitHub issue 251 in actions/download-artifact (link omitted to avoid creating a cross-reference)
- 7: GitHub issue 20249 in github/gh-aw (link omitted to avoid creating a cross-reference)
- 8: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/contexts.md
important: Gate verify-workflow with github.repository == 'NVIDIA/cccl'. On forks and private mirrors, build-workflow and its dependent dispatch jobs are skipped, but always() && !cancelled() still runs verify-workflow. The pinned actions/download-artifact step then fails because the required workflow artifact is absent. In this reusable workflow, github.repository resolves to the caller repository.
Source: Path instructions
| matrix-build: | ||
| name: Build & dispatch CI matrix | ||
| uses: ./.github/workflows/ci-matrix-build.yml | ||
| secrets: inherit | ||
| with: | ||
| job-array: ${{ toJSON(fromJSON(needs.build-workflow.outputs.workflow)['windows_standalone']['jobs'][matrix.name]) }} | ||
|
|
||
| verify-workflow: | ||
| name: Verify and summarize workflow results | ||
| if: ${{ always() && !cancelled() }} | ||
| needs: | ||
| - build-workflow | ||
| - dispatch-groups-linux-two-stage | ||
| - dispatch-groups-windows-two-stage | ||
| - dispatch-groups-linux-standalone | ||
| - dispatch-groups-windows-standalone | ||
| permissions: | ||
| contents: read | ||
| runs-on: ubuntu-latest | ||
| outputs: | ||
| failure_message: ${{ steps.check-workflow.outputs.failure_message }} | ||
| steps: | ||
| - name: Checkout repo | ||
| uses: actions/checkout@v6 | ||
| with: | ||
| persist-credentials: false | ||
|
|
||
| - name: Check workflow success | ||
| id: check-workflow | ||
| uses: ./.github/actions/workflow-results | ||
| with: | ||
| github_token: ${{ secrets.GITHUB_TOKEN }} | ||
| slack_token: ${{ secrets.SLACK_NOTIFIER_BOT_TOKEN }} | ||
| slack_log: ${{ secrets.SLACK_CHANNEL_CI_LOG }} | ||
| workflows: nightly |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
printf '%s\n' '--- repository conventions ---'
find /tmp/coderabbit-repo-knowledge/nvidia-cccl-2f773195 -maxdepth 2 -type f -name '*.md' -print
printf '%s\n' '--- nightly ---'
cat -n .github/workflows/ci-workflow-nightly.yml | sed -n '1,70p'
printf '%s\n' '--- weekly ---'
cat -n .github/workflows/ci-workflow-weekly.yml | sed -n '1,70p'
printf '%s\n' '--- custom ---'
cat -n .github/workflows/ci-workflow-custom.yml | sed -n '1,65p'
printf '%s\n' '--- reusable workflow permission declarations and callers ---'
rg -n -C 4 'permissions:|id-token:|contents:|workflow_call|ci-matrix-build' .github/workflows/ci-matrix-build.yml .github/workflows/ci-workflow-nightly.yml .github/workflows/ci-workflow-weekly.yml .github/workflows/ci-workflow-custom.ymlRepository: NVIDIA/cccl
Length of output: 26570
🌐 Web query:
GitHub Actions reusable workflow caller permissions cannot elevate id-token write called workflow default permissions
💡 Result:
It is a fundamental principle of GitHub Actions that reusable workflow permissions cannot be elevated by the called (reusable) workflow [1][2][3]. The effective permissions of a called workflow are restricted to the intersection of the permissions granted by the caller and those declared by the callee [4][5][6]. When a reusable workflow requires the id-token: write permission—commonly for OIDC-based cloud authentication—the calling workflow job must explicitly grant this permission [4][7][8]. If the caller does not grant id-token: write, the called workflow will fail at runtime (or during parse-time validation) because it cannot "elevate" its own token permissions beyond what the caller has provided [7][9][10]. To resolve this, you must: 1. Update the calling workflow job to include the permissions block granting id-token: write [4][7][5]. 2. Ensure the reusable workflow also declares id-token: write in the jobs that require it [4][5][6]. Example configuration for the caller: jobs: call-reusable: permissions: id-token: write contents: read uses:./.github/workflows/reusable.yml If the caller omits the permissions block entirely, the workflow will use the repository's default permissions, which are typically insufficient for id-token: write, leading to errors like "The workflow is requesting 'id-token: write', but is only allowed 'id-token: none'" [9][6][10].
Citations:
- 1: https://docs.github.com/en/enterprise-cloud@latest/actions/reference/workflows-and-actions/reusing-workflow-configurations
- 2: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 3: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md
- 4: https://latchkey.dev/learn/github-actions/reusable-workflow-id-token-not-granted-in-ci
- 5: https://latchkey.dev/learn/github-actions/gha-id-token-permission-reusable-workflow
- 6: https://latchkey.dev/learn/github-actions/reusable-workflow-permissions-not-propagated-in-ci
- 7: https://latchkey.dev/learn/github-actions/github-actions-id-token-permission-reusable-call
- 8: https://github.blog/changelog/2023-06-15-github-actions-securing-openid-connect-oidc-token-permissions-in-reusable-workflows/
- 9: i2mint/wads@33239ad
- 10: GitHub pull request 670 in rhysd/actionlint (link omitted to avoid creating a cross-reference)
Security Misconfiguration (CWE-732): Incorrect Permission Assignment for Critical Resource
Reachability: Internal · Exploitability: Theoretical
important: Grant contents: read and id-token: write to the matrix-build job in all three caller workflows. Without these permissions, ci-matrix-build.yml cannot obtain the scopes required by its dispatch jobs.
🧰 Tools
🪛 zizmor (1.29.0)
[warning] 19-180: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block
(excessive-permissions)
[warning] 35-40: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block
(excessive-permissions)
[warning] 37-37: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow
(secrets-inherit)
📍 Affects 3 files
.github/workflows/ci-workflow-nightly.yml#L35-L40(this comment).github/workflows/ci-workflow-weekly.yml#L34-L40.github/workflows/ci-workflow-custom.yml#L45-L48
Sources: Path instructions, Linters/SAST tools
😬 CI Workflow Results🟥 Finished in 2h 54m: Pass: 99%/609 | Total: 13d 13h | Max: 2h 53m | Hits: 61%/1311475See results here. AI failure analysis1. C Parallel v2 custom-type transform segfaults during device copy · 1 jobExplanation: The transform test process crashes while evaluating the host-to-device cudaMemcpy in pointer_t's vector constructor. The saved log has no stack trace or CUDA error, so it cannot distinguish a driver/runtime crash from earlier memory corruption that surfaced at this copy; the PR changes only workflow files. Evidence: Copy this prompt into a coding agentJobs: 2. Python segmented_sum example subprocess fails without diagnostics · 1 jobExplanation: Importing the module completes successfully, but the test harness then executes the same top-level example again in a child process, which exits unsuccessfully with empty stderr. Because the harness omits the child return code and stdout from the exception, the log cannot identify whether this was a Python error or a Windows process-level crash. Evidence: Copy this prompt into a coding agentJobs: 3. NVBench devcontainer sccache server startup timeout · 1 jobExplanation: The Linux devcontainer exits during initialization because sccache does not become ready within its startup timeout, before the NVBench helper test begins. No sccache server log or lower-level startup error is present, and the workflow-only PR diff does not explain the failure, so this is most consistent with an isolated runner or cache-service initialization failure. Evidence: Copy this prompt into a coding agentJobs: |
1 participant
Description
Gets CCCL workflows closer to being executed with different test matrices rather than the one available at the current commit. This PR allows invoking a workflow using a different CI matrix from a different branch.
I thought about just passing the ci matrix in as a single text input, but there's a 65k limit on inputs and figured we might hit that limit in the future.
Checklist