[Alexey-Rivkin]

What?

Do not start CI for draft PRs.

Why?

Azure behaviour change - now marking a draft PR "ready for review" makes Azure queue a second run of the same commit. This causes extra full runs, adding load to already strained resources.
Microsoft has no fix planned (https://developercommunity.visualstudio.com/t/11032682).

How?

buildlib/azure-pipelines-pr.yml:
drafts: false in the pr: block. One line.

[svc-nvidia-pr-review]

🤖 Starting review — findings will be posted here when done.

[svc-nvidia-pr-review]

Coverage gap: per REVIEW.md, CI changes should demonstrate that the stated behavior actually changed. PR triggers are evaluated from the source branch YAML, so this is verifiable by toggling this PR itself to draft and confirming no pipeline queues, then back to ready and confirming the runs start. Worth asking for that evidence if it isn't already in the PR discussion.

[Alexey-Rivkin]

/azp run UCX PR

[azure-pipelines]

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

[svc-nvidia-pr-review]

🤖 Starting review — findings will be posted here when done.

[svc-nvidia-pr-review]

🤖 Starting review — findings will be posted here when done.

[svc-ucx]

🤖 CI Triage Agent — UCX PR (AddressSanitizer roce on worker 0) · commit 706a1646

TL;DR: The AddressSanitizer "roce on worker 0" job was killed mid-compile by an Azure DevOps agent shutdown ("The agent has received a shutdown signal" → "The operation was canceled"), not by any UCX code/test failure — simply re-run the pipeline.

Full analysis

Summary: Job AddressSanitizer roce on worker 0 (build 135293) aborted while ./contrib/test_jenkins.sh was still compiling gtest sources; no test ever ran.

Root cause: Infrastructure-level cancellation, not a code defect. The log shows continuous, healthy build progress — object files completing every 1–15 s from 14:20:04 through 14:28:28 (largest gap ≈ 30 s, between 14:22:26 and 14:22:45), so nothing hung and nothing hit a wall-clock timeout. At 14:28:23 the agent emitted ##[error]The agent has received a shutdown signal. This can happen when the agent service is stopped, or a manually started agent is canceled. followed by ##[error]The Operation will be canceled and ##[error]The operation was canceled, then Finishing: Run ./contrib/test_jenkins.sh and Finalize Job. That message is produced by the self-hosted agent host going away (VM/container recycled, pool drained, or the run superseded/canceled), not by the build step failing. The last compile lines (uct/v2/test_uct_query.cc, uct/gtest-test_uct_perf.o) are unrelated bystanders. Consistent with this, the head commit on the branch, 706a1646 "CI: Do not start the PR pipeline for draft pull requests" (Alexey Rivkin), only adds drafts: false to the pr: trigger in buildlib/azure-pipelines-pr.yml:6 — it cannot affect a compilation step, though it does mean that toggling the PR to draft / pushing a new commit will cancel in-flight runs like this one.

Implicated commit: none — build was not failed by code. Branch head is [REDACTED:Hex High Entropy String] (Alexey Rivkin), which only edits the PR trigger.

File: buildlib/azure-pipelines-pr.yml:4-6 (only the PR-trigger change under test; no source file implicated in the abort)

Suggested fix: Re-queue the PR pipeline (or push an empty commit) — this is a transient agent loss. If it recurs on the same agent, ask CI ops to check the health/drain schedule of the self-hosted pool hosting the roce on worker 0 job (spot/scale-set recycling and container restarts produce exactly this message). Since the PR under test changes PR-trigger semantics, also confirm the run wasn't cancelled by the PR being switched to draft or by a superseding push before treating it as an agent problem; no UCX code change is warranted.

Related: PR #11932 (this PR, ci-no-draft-builds); prior trigger change 1ebb4fa "AZP: Exclude .ci/ from PR pipeline trigger (#11439)". No matching issue for the agent-shutdown signature.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id f7b8c526-a469-45b9-89a6-cc7135af1198 in the triage console for the audit trail.

[gleon99]

👍🏼