potiuk opened a new pull request, #71548: URL: https://github.com/apache/airflow/pull/71548
The per-job duration trend excludes one step, `Prepare breeze & CI image`, from a job's wall clock. The image-cache push jobs do not have that step — they build and push the image in a step of their own — so when a change to an early image layer invalidates everything after it, the resulting full rebuild and re-push is counted as work time and reported as a regression. The same CI-only prefix also missed every job that prepares a PROD image. Seen on the [2026-08-13 canary](https://github.com/apache/airflow/actions/runs/31661917904), the first scheduled run after [`516e4afba1`](https://github.com/apache/airflow/commit/516e4afba1) added an apt package to `install_os_dependencies.sh`: `Push CI latest images: 3.12` went 666s -> 1778s, and all ten cache-push jobs went from 7-13m to 14-31m. Image build time is meant to be handled by the persistence check, which only reports a slowdown lasting days rather than a single night. Known gap left alone: the dedicated `Build CI images` / `Build PROD images` jobs are still exposed to the same false positive. Their heavy step name is produced by a template with an empty interpolation (`Build linux/amd64:3.10 image`), so matching it by prefix is fragile; covering them properly means feeding those jobs into the image-build persistence check instead. --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes — Claude Code (Opus 5) Generated-by: Claude Code (Opus 5) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
