Skip to content

Harden publish workflow recovery, notifications, and dispatch guard - #130

Merged
glenn-jocher merged 1 commit into
mainfrom
publish-recovery
Jul 4, 2026
Merged

Harden publish workflow recovery, notifications, and dispatch guard#130
glenn-jocher merged 1 commit into
mainfrom
publish-recovery

Conversation

@glenn-jocher

@glenn-jocher glenn-jocher commented Jul 4, 2026

Copy link
Copy Markdown
Member

🛠️ Summary

Ports the release-workflow hardening from ultralytics/template#91 (and matching PRs in mkdocs/ultralytics). The publish.yml pipeline previously had no recovery path after a partial failure, and Slack could report success before the pipeline finished.

1. Failed releases can now be recovered via workflow_dispatch

Once the tag is pushed, any downstream failure (build, PyPI upload, SBOM) previously left the release unrecoverable — a re-run hit git tag -a on the existing tag and the check job died. Now, when the pypi dispatch input is checked, the run proceeds as a recovery re-run:

  • workflow_dispatch with pypi: true forces increment=True
  • Tagging is skipped when the tag already exists on origin (git ls-remote)
  • Release summarization is gated independently on release existence (gh release view), healing the tag-pushed-but-no-release state, and unshallows history first so the changelog resolves the true previous tag
  • previous_tag output is omitted on recovery re-runs (online == local) so the summarizer falls back to the real previous tag instead of comparing vX...vX
  • PyPI upload uses skip-existing: true; SBOM upload uses --clobber

A partially failed release can be re-run from any point and completes only what is missing.

2. Slack success can no longer fire prematurely

notify now includes sbom in needs and in the success/failure conditions, so the ✅ message reflects the entire pipeline rather than racing the SBOM job.

3. workflow_dispatch can no longer release a non-main commit

The check job now requires github.ref == 'refs/heads/main'.

🧪 Testing

  • YAML validated
  • Same change reviewed through multiple adversarial Codex review rounds (to LGTM) on Add publish.yml release workflow template#91, mkdocs, and ultralytics; the no-failure happy path is behavior-identical to the current workflow.

🛠️ PR Summary

Made with ❤️ by Ultralytics Actions

🌟 Summary

Improves the THOP release workflow to make PyPI publishing, GitHub releases, SBOM uploads, and Slack notifications more reliable and recoverable 🚀

📊 Key Changes

  • Restricts automated release checks to the main branch only, reducing accidental publishing from other branches 🔒
  • Adds support for manual PyPI dispatch recovery using the pypi workflow input 🛠️
  • Prevents duplicate Git tags and GitHub releases by checking whether they already exist before creating them ✅
  • Enables PyPI publishing with skip-existing: true to tolerate reruns after partial failures 📦
  • Updates SBOM release uploads to use --clobber, allowing replacement of existing SBOM files ♻️
  • Makes Slack notifications depend on both PyPI publishing and SBOM generation/upload success 📣
  • Improves previous-tag handling so release summaries can still work correctly during recovery reruns 📝

🎯 Purpose & Impact

  • Makes the release pipeline more resilient to interrupted or partially failed publishing runs 💪
  • Reduces risk of duplicate tags, duplicate releases, or failed reruns when artifacts already exist 🚧
  • Improves release transparency by ensuring SBOM artifacts are included before success notifications are sent 🔍
  • Helps maintainers recover failed releases more easily without manual cleanup or risky workarounds ⚙️
  • Provides users with more consistent and trustworthy package releases on PyPI and GitHub Releases 🌍

@UltralyticsAssistant UltralyticsAssistant added devops GitHub Devops or MLops enhancement New feature or request fixed Bug has been resolved labels Jul 4, 2026
@UltralyticsAssistant

Copy link
Copy Markdown
Member

👋 Hello @glenn-jocher, thank you for submitting a ultralytics/thop 🚀 PR! This automated message is here to help with initial review, and an Ultralytics engineer will assist as needed. Please review the following checklist to ensure a seamless integration of your workflow hardening changes:

  • Define a Purpose: Clearly explain the purpose of your fix or feature in your PR description, and link to any relevant issues. Ensure your commit messages are clear, concise, and adhere to the project's conventions.
  • Synchronize with Source: Confirm your PR is synchronized with the ultralytics/thop main branch. If it's behind, update it by clicking the 'Update branch' button or by running git pull and git merge main locally.
  • Ensure CI Checks Pass: Verify all Ultralytics Continuous Integration (CI) checks are passing. If any checks fail, please address the issues.
  • Update Documentation: Update the relevant documentation for any new or modified features.
  • Add Tests: If applicable, include or update tests to cover your changes, and confirm that all tests are passing.
  • Sign the CLA: Please ensure you have signed our Contributor License Agreement if this is your first Ultralytics PR by writing "I have read the CLA Document and I sign the CLA" in a new message.
  • Minimize Changes: Limit your changes to the minimum necessary for your bug fix or feature addition. "It is not daily increase but daily decrease, hack away the unessential. The closer to the source, the less wastage there is." — Bruce Lee

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 UltralyticsAssistant left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 PR Review

Made with ❤️ by Ultralytics Actions

No genuine issues found in the changed workflow. The updates are narrowly scoped and improve idempotency for tag/release creation, PyPI re-runs, SBOM upload, and notification gating without introducing an obvious regression.

@glenn-jocher
glenn-jocher merged commit b4e6a57 into main Jul 4, 2026
5 checks passed
@glenn-jocher
glenn-jocher deleted the publish-recovery branch July 4, 2026 19:03
@UltralyticsAssistant

Copy link
Copy Markdown
Member

Great work @glenn-jocher, and thank you for getting this merged! 🚀

“Success is not final, failure is not fatal: it is the courage to continue that counts.” — Winston Churchill

This PR brings that spirit directly into the THOP release workflow by making PyPI publishing, GitHub Releases, SBOM uploads, and Slack notifications more resilient, recoverable, and trustworthy. The added safeguards against duplicate tags/releases, rerun-friendly publishing, improved SBOM handling, and main-branch-only release checks all help ensure smoother releases and faster recovery when something goes wrong.

These improvements strengthen confidence for both maintainers and users, making every THOP release more reliable. Appreciate the thoughtful work! 🙌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

devops GitHub Devops or MLops enhancement New feature or request fixed Bug has been resolved

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants