[v3-3-test] Refresh the image registry cache in a workflow that cannot be cancelled (#71171) - #71173
Merged
Merged
Conversation
…ed (#71171) * Refresh the image registry cache in a workflow that cannot be cancelled A branch built on push refreshed its registry cache from inside the CI run, which cancels in progress on the next push. With no cache the build runs cold, which widens the window the next push cancels in, which leaves the cache missing -- v3-3-test held only the default Python version's amd64 cache because that was the one matrix entry that finished in time. The refresh also has to cover every Python version: a version with no cache entry builds from scratch on every run, and selective checks narrows the list on a text-only push. * Refresh constraints from a workflow of its own, covering every flavour The manual constraints refresh shared a workflow with the automatic uv.lock push, so it was filtered by that workflow's paths and buried under its name in the Actions list. The documented procedures pointed at local builds -- refresh_images.sh for the image cache, breeze commands for the constraints -- which need a buildx/qemu setup, a committer login to ghcr.io, and enough bandwidth to push the layers. The workflows need none of that, and unlike a local run they always cover every Python version and every constraint flavour. * Exempt a manually started cache refresh from the push cancellation A push-triggered refresh should give way to the next one -- it is building the cache of a commit that is no longer the tip. A manual run should not: it is started because the branch has no cache and the push runs are the thing that keeps getting cancelled. (cherry picked from commit e69c188)
vatsrahul1001
requested review from
amoghrajesh,
ashb,
bugraoz93,
choo121600,
ephraimbuddy,
gopidesupavan,
jason810496,
jedcunningham,
jscheffl and
potiuk
as code owners
August 5, 2026 12:18
vatsrahul1001
added a commit
that referenced
this pull request
Aug 5, 2026
…ed (#71171) (#71173) * Refresh the image registry cache in a workflow that cannot be cancelled A branch built on push refreshed its registry cache from inside the CI run, which cancels in progress on the next push. With no cache the build runs cold, which widens the window the next push cancels in, which leaves the cache missing -- v3-3-test held only the default Python version's amd64 cache because that was the one matrix entry that finished in time. The refresh also has to cover every Python version: a version with no cache entry builds from scratch on every run, and selective checks narrows the list on a text-only push. * Refresh constraints from a workflow of its own, covering every flavour The manual constraints refresh shared a workflow with the automatic uv.lock push, so it was filtered by that workflow's paths and buried under its name in the Actions list. The documented procedures pointed at local builds -- refresh_images.sh for the image cache, breeze commands for the constraints -- which need a buildx/qemu setup, a committer login to ghcr.io, and enough bandwidth to push the layers. The workflows need none of that, and unlike a local run they always cover every Python version and every constraint flavour. * Exempt a manually started cache refresh from the push cancellation A push-triggered refresh should give way to the next one -- it is building the cache of a commit that is no longer the tip. A manual run should not: it is started because the branch has no cache and the push runs are the thing that keeps getting cancelled. (cherry picked from commit e69c188) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #71171 to
v3-3-test.Moves the CI image-cache refresh into a standalone
refresh-image-registry-cache.ymlthat can't be cancelled by the next push (push and manual runs are grouped separately), forces all Python versions, removes the "Early" cache job from the regular build, and splits the manual constraints refresh intorefresh-constraints.yml. This speeds up v3-3-test's coldlinux/amd64builds.Reconciliation note
This wasn't a clean cherry-pick. An earlier backport (#71167) had accidentally landed a draft of this work on
v3-3-testunder the old filenamerefresh-image-cache.yml, which main never had. This backport therefore:refresh-image-cache.yml->refresh-image-registry-cache.yml, so the branch ends with exactly one cache-refresh workflow (matching main);additional-ci-image-checks.yml,update-constraints-on-push.yml,refresh-constraints.yml, bothdev/*.md, plus the referenced image) byte-for-byte with main;ci-amd.yml/ci-arm.yml(only the 7 shared inputs are removed, identically in both —check-ci-workflows-in-syncpasses) and intest_selective_checks.py(which keeps v3-3-test's base plus the one cache test).CI_AMD_PLATFORM/CI_ARM_PLATFORMdo not exist onv3-3-test, so the test import from main was intentionally not carried over.Verified locally: all pre-commit hooks pass (yamllint, zizmor, lychee, markdownlint,
check-ci-workflows-in-sync), and the kepttest_all_python_versions_with_all_versions_labeltest passes.Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.8) following the guidelines