Build: Cache NuGet packages in shared templates - #10
Open
danielchalmers wants to merge 1 commit into
Open
Conversation
Neither template cached the NuGet global packages folder, so every job in every calling repo did a cold restore. - template-build-test: 'code-quality-check' owns the cache; 'build-test' restores only, so the two parallel jobs don't race on the same key. - template-deploy-web-app: keyed on 'checkout-repository' rather than 'github.repository', since the deploy may check out a different repo. Key format matches the one already used in MudBlazor/MudBlazor, with the hash widened to cover Directory.Packages.props, Directory.Build.props and global.json. restore-keys gives a partial hit when only versions change.
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.
Neither shared template cached the NuGet global packages folder, so every job in every calling repo did a cold
dotnet restore. This addsactions/cacheto both.Changes
template-build-test.ymlNUGET_PACKAGESpointing at${{ github.workspace }}/.nuget/packages.code-quality-checkusesactions/cache@v6(restore + save).build-testusesactions/cache/restore@v6— restore only. Both jobs run in parallel and restore the same package set, so having a single writer avoids the two of them racing to reserve the same key and emittingUnable to reserve cachewarnings. Same split as the.github/actions/buildcomposite in MudBlazor/MudBlazor.template-deploy-web-app.ymlinputs.checkout-repositoryinstead ofgithub.repository. This template can check out a repo other than the caller —MudBlazor/MudBlazor'sdeploy-trymudblazor.ymldeploys fromMudBlazor/TryMudBlazor— and keying on the caller would make those two collide on one key with unrelated dependency sets.Cache key
The prefix matches the convention already in use in MudBlazor/MudBlazor, so this stays consistent if that repo later moves onto the shared template. Two deliberate differences from that repo's version:
Directory.Packages.props/Directory.Build.props/global.json, not just**/*.csproj. With central package management the versions often don't live in the csproj at all, so a csproj-only hash can go stale. TryMudBlazor hassrc/Directory.Build.props.restore-keysgives a partial hit when the hash changes, so a single bumped package doesn't force a fully cold restore.