bump-develop-version.yml

# Auto-bumps wheels.json's version on develop after a GA release lands on main.
#
# Workflow:
#   1. Maintainer cuts v4.0.1 (or whatever) on main.
#   2. release.yml publishes to wheels-dev/wheels Releases AND fires a
#      `bump-develop` repository_dispatch at this repo (only for stable
#      channel — snapshots and RCs don't bump develop).
#   3. THIS workflow fires on that dispatch, opens a PR against develop
#      bumping wheels.json's version to (just-released-patch + 1).
#   4. Maintainer rubberstamps the PR.
#   5. Next develop merge fires snapshot.yml with the new target embedded
#      in the snapshot version string.
#
# Why repository_dispatch instead of `release: published`?
#   release.yml's "Create GitHub Release" step uses the default GITHUB_TOKEN,
#   and per GitHub Actions docs, events emitted by GITHUB_TOKEN don't trigger
#   downstream workflows (with exceptions for workflow_dispatch and
#   repository_dispatch). The release:published event therefore never reached
#   us on the v4.0.0 GA. release.yml already fires repository_dispatch with
#   DOWNSTREAM_DISPATCH_TOKEN (a PAT) for homebrew/scoop, so we piggyback
#   on that proven channel. See #2609.
#
# This is the "no version decisions ahead of time" piece — the maintainer
# decides at GA tag time whether the release is a patch / minor / major;
# whatever they pick, this workflow bumps to next-patch as the snapshot baseline.
# If the next release ends up being a minor or major bump, the snapshot version
# string sorts strictly lower than any of those, so brew upgrade still works.
name: Bump Develop Version

on:
  repository_dispatch:
    types: [bump-develop]
  # Manual fallback — if release.yml's dispatch step ever fails or the
  # maintainer wants to re-run after a missed event, they can fire this
  # by hand with the version they want to bump *from* (e.g., 4.0.0).
  workflow_dispatch:
    inputs:
      released_version:
        description: 'Version that was just released (bare SemVer, e.g. 4.0.0)'
        required: true
        type: string

permissions:
  contents: write
  pull-requests: write

jobs:
  bump:
    runs-on: ubuntu-latest
    env:
      # repository_dispatch carries the version in client_payload.version
      # (set by release.yml's dispatch step). workflow_dispatch supplies it
      # via inputs.released_version. One of the two is always present.
      # Hoisted to env to keep ${{ ... }} interpolation out of run: blocks,
      # per the workflow-injection security hook. The value is regex-validated
      # in "Compute next snapshot target" before downstream use.
      RAW_RELEASED_VERSION: ${{ github.event.client_payload.version || inputs.released_version }}
    steps:
      - name: Checkout develop
        uses: actions/checkout@v6
        with:
          ref: develop
          fetch-depth: 1
          # Don't persist GITHUB_TOKEN as a git extraheader — peter-evans/create-pull-request
          # below sets its own Authorization, and two simultaneous extraheaders make GitHub
          # reject git operations with "Duplicate header: Authorization" → HTTP 400.
          # First hit on the v4.0.1 GA (run 26173817714); manual workaround was #2770.
          persist-credentials: false

      - name: Compute next snapshot target
        run: |
          # Strip leading 'v' if present. The dispatch payload normally has
          # no 'v' prefix (release.yml sources from wheels.json, which is
          # bare SemVer), but workflow_dispatch input might.
          STRIPPED="${RAW_RELEASED_VERSION#v}"
          # Fail loud on bad input — the primary repository_dispatch path is
          # guaranteed bare SemVer (release.yml only fires this for
          # CHANNEL=stable, which has already filtered out -snapshot/-rc
          # suffixes), so a mismatch here means the workflow_dispatch fallback
          # was used with an unparseable version. Exiting 0 would let the
          # downstream "Update wheels.json" step write '"version": ""' and
          # open a malformed PR; exit 1 keeps the run red so the operator
          # can re-fire with corrected input. See #2615 review.
          if [[ ! "${STRIPPED}" =~ ^([0-9]+)\.([0-9]+)\.([0-9]+)$ ]]; then
            echo "::error::Released version '${RAW_RELEASED_VERSION}' doesn't match SemVer M.m.p — cannot bump."
            exit 1
          fi
          MAJOR="${BASH_REMATCH[1]}"
          MINOR="${BASH_REMATCH[2]}"
          PATCH="${BASH_REMATCH[3]}"
          NEXT_PATCH=$((PATCH + 1))
          NEW_VERSION="${MAJOR}.${MINOR}.${NEXT_PATCH}"
          echo "Released: ${STRIPPED} -> next snapshot target: ${NEW_VERSION}"
          echo "NEW_VERSION=${NEW_VERSION}" >> $GITHUB_ENV
          echo "RELEASED_VERSION=${STRIPPED}" >> $GITHUB_ENV

      - name: Update wheels.json
        run: |
          jq --arg v "${NEW_VERSION}" '.version = $v' wheels.json > wheels.json.tmp
          mv wheels.json.tmp wheels.json
          echo "wheels.json now reads:"
          jq '.version' wheels.json

      - name: Open bump PR
        uses: peter-evans/create-pull-request@v6
        with:
          branch: "auto-bump/develop-${{ env.NEW_VERSION }}"
          title: "chore: bump develop snapshot target to ${{ env.NEW_VERSION }}"
          body: |
            Automated bump triggered by GA release `${{ env.RELEASED_VERSION }}`.

            Sets `wheels.json` version to `${{ env.NEW_VERSION }}` so subsequent
            develop snapshots are tagged `${{ env.NEW_VERSION }}-snapshot.<run>`.

            **This is a baseline, not a commitment.** If the next GA release
            ends up being a minor or major bump, the snapshot version strings
            still sort strictly lower than any of those, so the tap auto-bump
            and `brew upgrade` continue to work correctly. The maintainer makes
            the actual scope decision at the next GA's tag-cut time, not here.
          commit-message: "chore: bump develop snapshot target to ${{ env.NEW_VERSION }}"
          delete-branch: true