Queue publish runs and retry PyPI upload failures#205
Conversation
|
👋 Hello @glenn-jocher, thank you for submitting a
For more guidance, please refer to our Contributing Guide. Don't hesitate to leave a comment if you have any questions. Thank you for contributing to Ultralytics! 🚀 |
UltralyticsAssistant
left a comment
There was a problem hiding this comment.
🔍 PR Review
Made with ❤️ by Ultralytics Actions
The retry and attestation cleanup flow is coherent, but the new workflow-level concurrency group can silently skip queued releases unless it opts into a multi-run queue.
💬 Posted 1 inline comment
|
🎉 Merged—thank you @glenn-jocher for improving PyPI publishing reliability! As Benjamin Franklin said, “By failing to prepare, you are preparing to fail.” The new concurrency controls, retry handling, cleanup of partial attestations, and safe skipping of existing packages help prepare releases for transient failures and overlapping workflows, making Ultralytics package delivery more dependable. Your contribution is greatly appreciated! |
Summary
queue: max, preserving up to 100 pending releases.pypa/gh-action-pypi-publishonce after transient Sigstore/Rekor or PyPI failures.skip-existingfor partial-upload recovery.This applies the resilience fix from ultralytics/ultralytics#25331 consistently across active Ultralytics PyPI publishers.
Deleted: nothing — GitHub owns workflow scheduling, and the external PyPI action exposes no retry input while retaining partial attestation files after failure.
Validation
git diff --checkconcurrency.queue: maxsyntax; local actionlint 1.7.12 predates this property🛠️ PR Summary
Made with ❤️ by Ultralytics Actions
🌟 Summary
Improves PyPI publishing reliability by preventing overlapping releases and automatically retrying transient failures. 🚀
📊 Key Changes
🎯 Purpose & Impact