Remove buildConfig from sccache cache key to share across PR/rolling builds#127997
Merged
agocke merged 2 commits intodotnet:mainfrom May 10, 2026
Merged
Remove buildConfig from sccache cache key to share across PR/rolling builds#127997agocke merged 2 commits intodotnet:mainfrom
agocke merged 2 commits intodotnet:mainfrom
Conversation
Contributor
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adjusts the Azure Pipelines Cache key used for the sccache local cache so that PR builds can restore caches produced by rolling (main) builds, improving cache reuse across build types.
Changes:
- Removed
buildConfigfrom the sccacheCache@2key andrestoreKeysto avoid splitting cache namespaces between PR (Debug) and rolling (Release) builds. - Added inline documentation explaining why
buildConfigis excluded and what benefit it enables (warm-starting PR builds from rolling caches).
steveisok
approved these changes
May 9, 2026
…builds The sccache cache key included buildConfig (Debug for PRs, Release for rolling builds), creating separate cache namespaces. This meant PR builds could never warm-start from rolling-build caches. buildConfig reflects the *managed* Configuration (-c), but sccache only caches native (C/C++) compilations whose flags are controlled by RuntimeConfiguration (-rc), which is constant per leg regardless of buildConfig. Removing it lets PR builds restore caches saved by rolling builds in the main scope, giving ~99% hit rates on first push instead of 0%. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
3652bf0 to
6bc7ee9
Compare
6bc7ee9 to
bab3ecb
Compare
The stackalloc of uninitialized memory requires an unsafe context. Wrap it in an unsafe block rather than marking the entire method unsafe. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
bab3ecb to
ce73855
Compare
Member
Author
|
/ba-g remote exec failure |
Member
Author
|
/ba-g first ba-g didn't work |
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
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.
Note
This PR description was generated with the assistance of GitHub Copilot.
Summary
Remove
buildConfig(Debug/Release) from the sccache ADO Pipeline Cache key so that PR builds can warm-start from rolling-build caches.Problem
The sccache cache key included
buildConfig, which isDebugfor PR builds andReleasefor rolling builds. This created completely separate cache namespaces, meaning:sccache|...|Release|...keys in therefs/heads/mainscopesccache|...|Debug|...keys, never finding rolling build cachesWhy this is safe
The native compiler flags are determined by
-rc(RuntimeConfiguration), not-c(Configuration):-rc(native)-c(managed) PR-c(managed) RollingSince
-rcis hardcoded per leg, the CMake build type and native compiler flags are identical between PR and rolling builds. The-cflag only affects managed code, which sccache doesn't cache.Expected impact
PR builds will restore sccache caches from rolling builds (saved in the main scope), giving ~99% hit rates on first push — a 33-46% reduction in build time for the linux-x64 native compilation legs based on prior analysis.