Bound Azure Pipelines selector history and publish cost
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
Hướng nghiên cứu
Bắt đầu trong src/AzurePipelines/PipelineCachingCacheClient.cs tại GetSelectors(...).ToHashSetAsync và TODO về việc giới hạn các selector được lưu trữ. Theo dõi cách các khóa selector có dấu thời gian, manifest và các lượt tải xuống tập hợp đường dẫn được xử lý, sau đó thêm các bài kiểm thử cho sự thay đổi liên tục của selector, loại bỏ trùng lặp, loại bỏ, kích thước manifest bị giới hạn và các yêu cầu từ xa. Hoàn thành khi việc lưu giữ và phát hành vẫn được giới hạn, đồng thời các selector được giữ lại vẫn cung cấp các lần cache hit như mong đợi.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- C#
- Star
- 64
- Fork
- 24
- Merge trung bình
- 1 ngày 14 giờ
- Pull request đã merge (30 ngày)
- 2
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của microsoft/MSBuildCache
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
microsoft/MSBuildCache#154 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
microsoft/MSBuildCache#167 · 2 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
microsoft/MSBuildCache#159 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
microsoft/MSBuildCache#155 · 1 bình luận ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
microsoft/MSBuildCache#149 · 3 bình luận ·
Tất cả issue của microsoft/MSBuildCache
Issue tương tự
-
bug frontend good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
NavigationViewItemAutomationPeer implements IInvokeProvider but never advertises the Invoke pattern Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
unoplatform/uno#24629 ·
-
agentic-workflows Needs: Triage :mag: State: In-PR
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
CS0162 "Unreachable code detected" warning from a MSBuildTemp .tmp file in every game project Đang mởbug
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
-
Type: enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
apache/arrow-adbc#4809 ·