Skip to content

ci: split build.yaml concurrency group by build_type#1211

Merged
rapids-bot[bot] merged 1 commit into
mainfrom
ci/split-build-concurrency-by-build-type
May 14, 2026
Merged

ci: split build.yaml concurrency group by build_type#1211
rapids-bot[bot] merged 1 commit into
mainfrom
ci/split-build-concurrency-by-build-type

Conversation

@rgsl888prabhu
Copy link
Copy Markdown
Collaborator

@rgsl888prabhu rgsl888prabhu commented May 13, 2026

Summary

  • The concurrency group in build.yaml was keyed on workflow + ref, so a push to main (or release/*) would cancel an in-progress nightly-dispatched build.yaml run on the same branch — and the reverse was equally true.
  • Add the build_type input to the group key (falling back to 'branch' when inputs is unset on push) so nightly and branch builds occupy separate groups.
  • Same-type, same-ref runs still cancel older runs (e.g. rapid pushes to main still supersede each other).

🤖 Generated with Claude Code

Previously the concurrency group was keyed only on workflow + ref, so a
push to main would cancel an in-progress nightly-dispatched build.yaml
run on the same branch (and vice versa). Add the build_type input (with
'branch' as the fallback for push events) to the group key so nightly
and branch builds occupy separate groups, while still cancelling older
runs of the same type on the same ref.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
@rgsl888prabhu rgsl888prabhu requested a review from a team as a code owner May 13, 2026 15:47
@rgsl888prabhu rgsl888prabhu requested a review from bdice May 13, 2026 15:47
@rgsl888prabhu rgsl888prabhu self-assigned this May 13, 2026
@rgsl888prabhu rgsl888prabhu added non-breaking Introduces a non-breaking change improvement Improves an existing functionality labels May 13, 2026
Copy link
Copy Markdown
Member

@jameslamb jameslamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh cool idea!

A nightly run cancelling one triggered from a merge is mildly annoying only because it delays package publishing, but I think not that big of a problem.

However, a merge cancelling a nightly build is more serious. Because the nightly CI polls for a single, specific workflow run (rapidsai/trigger-workflow-and-wait code link), in that situation where there's a merge while the nightly build is going on, the nightly build will be cancelled and the nightly tests will never run.

I support trying this, and we should probably do it across all of RAPIDS. I'll put up a build-planning issue proposing that and see what folks think.


concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
group: ${{ github.workflow }}-${{ github.ref }}-${{ inputs.build_type || 'branch' }}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense to me. Just noting I looked into this here: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts#github-context

github.ref should be identical and set to just the branch name for both a push and workflow_dispatch run, I think, so it makes sense that those would conflict.

@rgsl888prabhu
Copy link
Copy Markdown
Collaborator Author

/merge

@rapids-bot rapids-bot Bot merged commit be9b398 into main May 14, 2026
307 of 314 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

improvement Improves an existing functionality non-breaking Introduces a non-breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants