BUILD-10699: test fallback-to-default-branch cache behaviour#1918
Closed
BUILD-10699: test fallback-to-default-branch cache behaviour#1918
Conversation
|
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
1 participant
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.
Purpose
Test PR for BUILD-10699 — validating the new
fallback-to-default-branchbehaviour in gh-action_cache#42.Both cache steps have been migrated from the deprecated
ci-github-actions/cachewrapper togh-action_cachedirectly, pinned to the feature branch SHA2cffd56which addsfallback-to-default-branch: trueas a default.Do not merge. This PR exists only for CI testing.
What changed
Both cache usages in
build.ymlnow point at thegh-action_cachefeature branch:test-linuxjob) —key: sonar-scanner-Linux, norestore-keysqajob) —key: cache-Linux-{month}-{matrix.name}, norestore-keysWith the new default behaviour, both will automatically get a fallback restore key pointing to the
masterbranch cache, even though norestore-keysare explicitly set.Test Plan
Test 1 — Sonar Scanner cache (
test-linuxjob)Cache step:
Cache Sonar Scanner artifactsKey:
sonar-scanner-Linuxrestore-keys: none (relying on new default)
prepare-keysstep outputsbranch-restore-keyscontainingrefs/heads/master/sonar-scanner-Linuxruns-on/cachestep logs show it attempted restore with keyBUILD-10699-test-fallback-to-default-branch/sonar-scanner-Linuxand fallbackrefs/heads/master/sonar-scanner-LinuxBUILD-10699-test-fallback-to-default-branch/sonar-scanner-Linuxcache-hit: trueoutput, restore time is fastTest 2 — Orchestrator cache (
qajob, matrix: SQLatest, SQLts99)Cache step: unnamed orchestrator cache step
Key:
cache-Linux-{YYYY-MM}-{matrix.name}(e.g.cache-Linux-2026-03-SQLatest)restore-keys: none (relying on new default)
prepare-keysoutputsbranch-restore-keys = refs/heads/master/cache-Linux-2026-03-SQLatestruns-on/cachelogs show fallback keyrefs/heads/master/cache-Linux-2026-03-SQLatestwas foundBUILD-10699-test-fallback-to-default-branch/cache-Linux-2026-03-SQLatestcache-hit: trueTest 3 —
fallback-to-default-branch: false(opt-out)Not tested in this PR (no opt-out case here). Covered by unit testing of
prepare-keys.shdirectly.Test 4 — On
masterbranch (no fallback expected)When this same workflow runs on
master, theprepare-keysstep should detect it's already on the default branch and not add any fallback restore keys. Verify by inspecting a master build'sprepare-keysstep output —branch-restore-keysshould be empty.How to verify
For each CI run triggered by this PR, inspect the "Prepare cache keys" step output in the Actions log. You should see:
The presence of
branch-restore-keyspointing tomaster— even without anyrestore-keysinput — is the primary success signal.🤖 Generated with Claude Code