Use a binary cache for vcpkg in pipelines - #5936
Flor Chacón (florelis) wants to merge 2 commits into
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Re-running the pipeline because the job that failed in the last build mostly worked in a job re-run, but failed due to duplicated pipeline artifacts |
ranm-msft
left a comment
There was a problem hiding this comment.
Is it intentional for PR validation to populate the shared cache? VCPKG_BINARY_SOURCES is set at pipeline scope with readwrite, and since this same file serves both the master trigger and the PR trigger, PR runs will also try to upload whatever they end up building, assuming the build identity has publish rights on WinGetDependencies. Fork PRs won't get the credential so in practice that's branch PRs from people with push access, but it still means the cache gets written from unreviewed states.
Would it be worth holding PR runs to read and leaving automatic population to master?
${{ if eq(variables['Build.Reason'], 'PullRequest') }}:
VCPKG_BINARY_SOURCES: "clear;nuget,<url>,read"
${{ else }}:
VCPKG_BINARY_SOURCES: "clear;nuget,<url>,readwrite"To be clear that isn't an isolation boundary. NuGetAuthenticate still hands the job a credential either way, so this only stops the uploads from happening by default; it doesn't stop code in the job from pushing deliberately. If you want real separation it'd have to be a read-only identity for PR builds.
Separately, this has been open since December and has picked up conflicts. Is it still something you want to land, or has the vcpkg situation moved on since then?
This should speed up each pipeline run by a few minutes.
It can also be configured locally by setting the environment variable
VCPKG_BINARY_SOURCEStonuget,https://pkgs.dev.azure.com/shine-oss/winget-cli/_packaging/WinGetDependencies/nuget/v3/index.jsonI configured it at the pipeline level instead of adding it to the projects to not interfere with the configuration used in internal builds.
Microsoft Reviewers: Open in CodeFlow