This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/main by this push:
new e99daee1c15 Reduce noise in the daily CI duration trend alert (#69113)
e99daee1c15 is described below
commit e99daee1c154b77d807f45c0e3b00a6660980238
Author: Jarek Potiuk <[email protected]>
AuthorDate: Fri Jul 3 15:45:52 2026 +0200
Reduce noise in the daily CI duration trend alert (#69113)
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 2f3e1398d29..08e6b6b2657 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"
