Bound Azure Pipelines selector history and publish cost
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
Línea de trabajo
Comienza en src/AzurePipelines/PipelineCachingCacheClient.cs, en GetSelectors(...).ToHashSetAsync y el TODO sobre limitar los selectores almacenados. Traza cómo se gestionan las claves de selector con marca de tiempo, los manifiestos y las descargas de conjuntos de rutas, y después añade pruebas para la rotación de selectores, la deduplicación, la expulsión, un tamaño de manifiesto acotado y las solicitudes remotas. El trabajo estará terminado cuando la retención y la publicación sigan estando acotadas, mientras que los selectores retenidos sigan proporcionando aciertos de caché esperados.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- C#
- Estrellas
- 64
- Forks
- 24
- Merge medio
- 1 d 14 h
- PR fusionados (30 d)
- 2
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/MSBuildCache
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
microsoft/MSBuildCache#154 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
microsoft/MSBuildCache#167 · 2 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
microsoft/MSBuildCache#159 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
microsoft/MSBuildCache#155 · 1 comentario ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
microsoft/MSBuildCache#149 · 3 comentarios ·
Todos los issues de microsoft/MSBuildCache
Issues similares
-
core dependencies
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
-
bug frontend good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
NavigationViewItemAutomationPeer implements IInvokeProvider but never advertises the Invoke pattern Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
unoplatform/uno#24629 ·
-
agentic-workflows Needs: Triage :mag: State: In-PR
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Down / Waiting for removal
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100