Bound Azure Pipelines selector history and publish cost
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
Direzione di ricerca
Inizia in src/AzurePipelines/PipelineCachingCacheClient.cs, in GetSelectors(...).ToHashSetAsync e nel TODO relativo alla limitazione dei selettori memorizzati. Traccia come vengono gestiti le chiavi dei selettori con timestamp, i manifest e i download degli insiemi di percorsi, quindi aggiungi test per la rotazione dei selettori, la deduplicazione, l’eliminazione, una dimensione dei manifest limitata e le richieste remote. Il lavoro è completato quando la conservazione e la pubblicazione rimangono limitate, mentre i selettori conservati continuano a fornire i risultati della cache previsti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- C#
- Stelle
- 64
- Fork
- 24
- Merge medio
- 1g 14h
- PR unite (30g)
- 2
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di microsoft/MSBuildCache
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
microsoft/MSBuildCache#154 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
microsoft/MSBuildCache#167 · 2 commenti ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
microsoft/MSBuildCache#159 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
microsoft/MSBuildCache#155 · 1 commento ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
microsoft/MSBuildCache#149 · 3 commenti ·
Tutte le issue di microsoft/MSBuildCache
Issue simili
-
bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
sillsdev/languageforge-lexbox#2665 ·
-
bug documentation frontend
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
azurenoops/spin_agent#975 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
:watch: Not Triaged 11.0 fundamentals/subsvc
Difficoltà 2/5 1-3 ore Idoneità per principianti 92/100
dotnet/AspNetCore.Docs#37699 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
SubtitleEdit/subtitleedit#15108 · 1 commento ·