Skip to content

Use a binary cache for vcpkg in pipelines - #5936

Open
Flor Chacón (florelis) wants to merge 2 commits into
masterfrom
user/florelis/vcpkgcache
Open

Flor Chacón (florelis) wants to merge 2 commits into
masterfrom
user/florelis/vcpkgcache

Conversation

@florelis

@florelis Flor Chacón (florelis) commented Dec 18, 2025 •

Copy link
Copy Markdown
Member

This should speed up each pipeline run by a few minutes.

It can also be configured locally by setting the environment variable VCPKG_BINARY_SOURCES to nuget,https://pkgs.dev.azure.com/shine-oss/winget-cli/_packaging/WinGetDependencies/nuget/v3/index.json

I 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

@florelis
Flor Chacón (florelis) requested a review from a team as a code owner December 18, 2025 05:29
@JohnMcPMS

Copy link
Copy Markdown
Member

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@florelis

Copy link
Copy Markdown
Member Author

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@florelis

Copy link
Copy Markdown
Member Author

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 ranm-msft left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants