Skip to content

[v3-3-test] Refresh the image cache on canary pushes, not only on the schedule (#71137) #71138

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
potiuk merged 1 commit into from
Aug 5, 2026
Merged

[v3-3-test] Refresh the image cache on canary pushes, not only on the schedule (#71137) #71138

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 16 additions & 8 deletions .github/workflows/additional-ci-image-checks.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand Down
Loading