ci: supersede stale PR build runs + skip draft PRs

[finger563]

What & why

Two CI ergonomics improvements to the heavy build workflows:

1. Supersede stale runs — a new commit on a PR now cancels that PR's in-progress build runs, so we don't burn minutes finishing builds for a commit that's already been replaced.
2. Skip draft PRs — build CI no longer runs on draft PRs (still runs on ready PRs and on push-to-main / releases).

Changes

Added to build.yml, build_libraries.yml, and build_wheels.yml:

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

• Keyed by PR number (globally unique — unlike head-branch names, which two fork PRs can collide on), falling back to github.ref for push/release.
• cancel-in-progress is gated to pull_request so push-to-main and release runs are never cancelled (the one nuance vs. rtps_interop.yml, which this mirrors but which is PR-only).

Draft guard on each heavy build job:

if: github.event_name != 'pull_request' || github.event.pull_request.draft == false

(Applied to build; build_windows/build_linux/build_macos; build_wheels/build_sdist. Push-to-main is unaffected since the event isn't pull_request.)

Left unchanged (intentional)

publish_pypi (release-only, never on PRs), static_analysis, build_and_publish_docs, upload_components (not PR build matrices), and rtps_interop.yml (already has the pattern).

Verification

YAML validity checked for each edited workflow; logic reviewed (triggers intact, draft guard never skips main, concurrency group correct). GitHub Actions can't run locally, so this is validity + review.

🤖 Generated with Claude Code

[github-actions]

✅Static analysis result - no issues found! ✅

[Copilot]

Pull request overview

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Improves CI ergonomics for heavy build workflows by canceling stale PR runs on new commits and skipping build jobs for draft PRs.

Changes:

• Added workflow-level concurrency with PR-number grouping and PR-only cancel-in-progress gating.
• Added job-level if: conditions to skip heavy build jobs on draft PRs.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
.github/workflows/build.yml	Adds concurrency + draft-PR job guard to reduce wasted CI cycles on PR updates.
.github/workflows/build_libraries.yml	Adds concurrency + draft-PR job guards for OS build jobs.
.github/workflows/build_wheels.yml	Adds concurrency + draft-PR job guards for wheel/sdist builds.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (2)

.github/workflows/build.yml:27

• The PR description states the concurrency group falls back to github.ref for non-PR events, but the implementation falls back to github.run_id. Either update the PR description to match the implemented behavior, or change the workflow to use github.ref (per the description) if you intended to group non-PR runs by ref.

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

.github/workflows/build_wheels.yml:33

• In this workflow, on: only includes pull_request, so the comment block describing non-PR events (push/release) and the run_id fallback is misleading here. Consider trimming the comment to PR-only behavior (or adding the relevant triggers if non-PR events are actually intended for this workflow).

# Supersede in-progress runs: a new commit on the same PR cancels the earlier,
# now-stale build. Keyed by the workflow (so it never cross-cancels other
# workflows) + the PR number, which is globally unique - unlike the head branch
# name, two fork PRs can't collide on it. For non-PR events (push, release) we
# fall back to github.run_id, which is unique per run, so those runs each get
# their own group and never serialize or cancel each other.
# cancel-in-progress is gated to pull_request events only so that push-to-main
# (and release) runs are never cancelled.