This is an automated email from the ASF dual-hosted git repository. potiuk pushed a commit to branch early-cache-push-on-canary-pushes in repository https://gitbox.apache.org/repos/asf/airflow.git
commit 1f2f87c4a8f757bb0a9a728987a3f0011aec350e Author: Jarek Potiuk <[email protected]> AuthorDate: Wed Aug 5 11:36:53 2026 +0800 Refresh the image cache on canary pushes, not only on the schedule Release branches are built by push only, and their cache refresh sat behind the whole test matrix. A red branch never refreshed its cache at all, and the staler it got the slower it was to turn green -- v3-3-test went eight days without a refresh while its runs kept failing. --- .github/workflows/additional-ci-image-checks.yml | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/.github/workflows/additional-ci-image-checks.yml b/.github/workflows/additional-ci-image-checks.yml index c294dcf0dc8..d0a4cb55fa6 100644 --- a/.github/workflows/additional-ci-image-checks.yml +++ b/.github/workflows/additional-ci-image-checks.yml @@ -83,13 +83,23 @@ on: # yamllint disable-line rule:truthy permissions: contents: read jobs: - # Push early BuildX cache to GitHub Registry in Apache repository, This cache does not wait for all the - # tests to complete - it is run very early in the build process for "main" merges in order to refresh - # cache using the current constraints. This will speed up cache refresh in cases when pyproject.toml - # changes or in case of Dockerfile changes. Failure in this step is not a problem (at most it will - # delay cache refresh. It does not attempt to upgrade to newer dependencies. + # Push early BuildX cache to GitHub Registry in Apache repository. This cache does not wait for all the + # tests to complete - it is run very early in the build process in order to refresh cache using the + # current constraints. This will speed up cache refresh in cases when pyproject.toml changes or in case + # of Dockerfile changes. Failure in this step is not a problem (at most it will delay cache refresh). + # It does not attempt to upgrade to newer dependencies. # We only push CI cache as PROD cache usually does not gain as much from fresh cache because # it uses prepared airflow and provider distributions that invalidate the cache anyway most of the time + # + # Runs on `push` as well, not only on the scheduled canary. Release branches (`v*-*-test`) are built + # by `push` only, and their other refresh path -- the Regular cache push in `finalize-tests.yml` -- sits + # behind the whole test matrix. A branch that is red therefore never refreshes its cache at all, and the + # staler the cache gets the slower it is to turn green again. `main` is unaffected either way: it is not + # built on push, so it keeps refreshing through the scheduled canary. + # + # Pull requests stay excluded -- `canary-run` is also true for a PR carrying the `canary` label, and + # pushing cache from an unmerged branch is not something a label should authorise. This is the same + # condition the Regular cache push uses. push-early-buildx-cache-to-github-registry: name: Push Early Image Cache uses: ./.github/workflows/push-image-cache.yml @@ -111,9 +121,7 @@ jobs: include-success-outputs: ${{ inputs.include-success-outputs }} docker-cache: ${{ inputs.docker-cache }} disable-airflow-repo-cache: ${{ inputs.disable-airflow-repo-cache }} - if: > - inputs.canary-run == 'true' && - (github.event_name == 'schedule' || github.event_name == 'workflow_dispatch') + if: inputs.canary-run == 'true' && github.event_name != 'pull_request' # Check that after earlier cache push, breeze command will build quickly # This build is a bit slow from in-the scratch builds, so we should run it only in
