Feature request : avoid unecessary HTTP mirror update when nothing changed
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 50/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- go
- Lĩnh vực
- networking
Hướng nghiên cứu
The payload names no files, so start from the aptly mirror update command and the HTTP downloader it uses to fetch Release/InRelease from the mirror URL. Check aptly mirror show -json to confirm LastDownloadDate is already persisted, since that value is what the request's If-Modified-Since header would carry. Done means a 304 response skips the download and exits cleanly, while a 200 proceeds exactly as today.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
(First thank you Aptly team for this great tool !)
Found myself in a work where I have to mirror several repositories, then filter, merge and publish a new one.
These repo are updated on really different ways : some are updated 4 times a day, while other only change on a monthly basis.
Every time my script invoke "aptly mirror update", it can take a very long time depending on the network conditions.
To improve my script execution time I had to create a small shell script around "aptly mirror update" to avoid updating unchanged mirror.
Something like (pseudo code):
TIMECOND = $(aptly mirror show -json $REPONAME | jq -r .LastDownloadDate)
Then :
CODE=$(curl --head --time-cond $TIMECOND $REPO_URL/Release)
if [ $CODE -eq 304 ] ; then exit 0 ; fi
It would be great to have this feature directly in Aptly.
It could be done by adding a header on the metadata HTTP get request, with the already known lastDownloadDate :
If-Modified-Since: Fri, 21 Aug 2026 12:08:56 UTC
And deal with the answer either 200 (new file, go on) or 304 (unchanged, skip download)
(edit : fix mis-negate sentence)
- Ngôn ngữ chính
- Go
- Star
- 2.9k
- Fork
- 436
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
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 aptly-dev/aptly
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 80/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 54/100
Tất cả issue của aptly-dev/aptly
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 2 ngày
-
test-failure
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
teramoby/speedle-plus#129 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
containerd/containerd#14485 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày