Bound Azure Pipelines selector history and publish cost

Open
#164 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
csharp
Domain
tooling

Research direction

Start in src/AzurePipelines/PipelineCachingCacheClient.cs at GetSelectors(...).ToHashSetAsync and the TODO about limiting stored selectors. Trace how timestamped selector keys, manifests, and path-set downloads are handled, then add tests for selector churn, deduplication, eviction, bounded manifest size, and remote requests. Done means retention and publishing work remain bounded while retained selectors still provide expected cache hits.

Written by the indexing model from the issue text.

Description

Summary

The Azure Pipelines cache backend carries forward every selector ever observed for a weak fingerprint and republishes the complete set on each new selector.

Impact

For a recurring weak fingerprint whose path set or strong selector changes over time, each miss fetches the prior selector manifest, downloads every unique historical path set, writes temporary files, and republishes the full set. Publish work grows linearly with selector history rather than remaining bounded. Azure retention and selector deduplication limit some scenarios, but a long-lived cache universe can still accumulate substantial sequential remote I/O.

Evidence

src/AzurePipelines/PipelineCachingCacheClient.cs calls GetSelectors(...).ToHashSetAsync, adds the current selector, then iterates all selectors and republishes them. The implementation already contains TODO: limit the number of selectors we store. Timestamped selector keys carry the newest set across builds.

Suggested fix

Introduce a bounded retention policy for selectors per weak fingerprint, preserving the most useful/recent entries. Avoid downloading historical path-set content that will not be retained. Add instrumentation or tests demonstrating bounded manifest size and remote requests.

Acceptance criteria

  • Selector count and manifest size remain bounded under repeated selector churn.
  • Existing selectors still provide expected cache hits within the retention policy.
  • Publishing a new selector performs bounded remote work.
  • Tests cover churn, deduplication, and eviction behavior.
Dominant language
C#
Stars
64
Forks
24
Avg merge
1d 14h
Merged PRs (30d)
2

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/MSBuildCache

All issues in microsoft/MSBuildCache

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.