From c58fa46de2c5f1ea32c3c8ffff49900c166b848d Mon Sep 17 00:00:00 2001 From: Jarek Potiuk Date: Mon, 29 Jun 2026 08:45:03 +0200 Subject: [PATCH] Reduce noise in the daily CI duration trend alert MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The duration monitor flagged jobs by comparing a single nightly canary run against the median of the preceding runs, so any one slow run — slow PyPI, runner queue pressure, a cold cache — tripped the alert. Because a different run was "latest" each day, a different set of jobs was flagged each day, and network-bound constraint-resolution jobs that legitimately swing tens of minutes dominated nearly every alert. The result was a near-daily alert whose contents swung wildly and carried little signal. Compare the median of the last few nightly runs against the baseline so the two sides are symmetric and one unlucky run no longer trips it, and require a larger absolute jump before flagging individual jobs. Pin the monitor to successful (green) canary runs only. A failed or cancelled canary stops partway, so its truncated wall-clock and per-job durations would skew the baseline downwards and mask real regressions. The script already defaults to this, but the guarantee is now explicit at the call site so it cannot be silently changed. --- .github/workflows/ci-duration-monitor.yml | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/.github/workflows/ci-duration-monitor.yml b/.github/workflows/ci-duration-monitor.yml index bc0f093203abe..6008223245c65 100644 --- a/.github/workflows/ci-duration-monitor.yml +++ b/.github/workflows/ci-duration-monitor.yml @@ -49,7 +49,20 @@ jobs: # main coverage comes from the scheduled canary runs of the AMD workflow. WORKFLOW_NAME: "ci-amd.yml" BRANCH: "main" + # Only successful (green) canary runs feed the baseline — a failed or cancelled + # canary stops partway, so its truncated wall-clock and per-job durations would + # skew the trend downwards and mask real regressions. Set explicitly so the + # green-only guarantee is visible at the call site and can't be silently changed. + ONLY_SUCCESSFUL: "true" MAX_RUNS: "25" + # Compare the median of the last few nightly runs (not a single run) against the + # baseline so one unlucky run — slow PyPI, runner queue pressure, cold cache — does + # not trip the alert. With LATEST_RUNS=1 both sides were asymmetric (raw point vs + # median) and the alert fired most nights on whichever jobs happened to be slow. + LATEST_RUNS: "3" + # Network-bound jobs (constraint resolution, provider installs) legitimately swing + # tens of minutes run-to-run; require a larger sustained jump before flagging them. + JOB_MIN_ABS_INCREASE_MINUTES: "6" OUTPUT_FILE: "slack-message.json" - name: "Post duration alert to Slack"