Automate workflow-dispatched PyPI and GitHub releases

[Copilot]

✅ PR Checklist

This updates the release workflow so a manual dispatch from main can cut a release end-to-end: resolve the next version automatically (or accept an explicit override), create the tag, publish artifacts, and then fast-forward main only after release publication succeeds.

• Release flow

  • build_wheels.yml now supports two dispatch modes:
    • push/tag: existing release path
    • manual from main: compute/write VERSION, create/push the tag, publish from that tag, then update main
  • tagged reruns remain supported without allowing a version override

• Version resolution

  • adds .github/scripts/release_version.py to centralize version selection
  • default behavior increments the rightmost numeric component
  • explicit versions are accepted only if they parse as valid PEP 440 versions

• Rerun / race hardening

  • serializes release executions with workflow concurrency
  • makes GitHub release publication idempotent on tagged reruns by uploading artifacts if the release already exists
  • avoids advancing main before the tagged publish path succeeds

• Coverage

  • adds focused tests for:
    • version increment / override / invalid input handling
    • workflow structure guarantees for manual release prep, tagged reruns, concurrency, and main update behavior

on:
  workflow_dispatch:
    inputs:
      version:
        description: Optional release version
        required: false
        type: string

✅ Testing & CI

• Have tested the changes in my local environment, else have properly conveyed in the PR description
• The change includes a GitHub Action to test the script(if it is possible to be added).
• No existing GitHub Actions are failing because of this change.

📚 Documentation

• README or help docs are updated for new features or changes.
• CLI help messages are meaningful and complete.

📁 File Hygiene & Output Handling

• No unintended files (e.g., logs, cache, temp files, pycache, output folders) are committed.

🛡️ Safety & Security

• No secrets or credentials are committed.
• Paths, shell commands, and environment handling are safe and portable.

🙌 Contribution Hygiene

• PR title and description are concise and clearly state the purpose of the change.
• Related issues (if any) are properly referenced using Fixes # or Closes #.
• All reviewer feedback has been addressed.

• Fixes Automate the release process #319

[github-actions]

MLCommons CLA bot All contributors have signed the MLCommons CLA ✍️ ✅

[anandhu-eng]

This workflow looks simpler than #292 . Few points:

• since main is protected, the GITHUB_TOKEN might not have enough permission. The GitHub app mlc-automations is given with enough permission to do so. Refer: https://github.com/mlcommons/mlcflow/blob/main/.github/workflows/format.yml
• By claude: Instead of tagging the commit, publishing to PyPi,github and then pushing to main. Try to push the changes to VERSION to main and then do tagging and publishing

[arjunsuresh]

@copilot can you address the previous comment?

[Copilot]

@copilot can you address the previous comment?

Addressed in af827fa.

The workflow now uses the mlc-automations app token for checkout/push/release operations, pushes the VERSION bump to main before tagging/publishing, skips existing PyPI uploads on tagged reruns, and guards main reruns so they instruct the operator to rerun against the created tag instead of silently cutting the next version.