ci: allow prerelease branch releases

[hassiebp]

Summary

• allow the release workflow to run from non-main branches only for prerelease bumps (prepatch, preminor, premajor) with an explicit alpha, beta, or rc prerelease type
• keep official patch, minor, and major releases restricted to main
• push the release commit back to the triggering branch instead of hardcoding main

Root Cause

The release workflow had an early refs/heads/main guard and later pushed the version commit with git push origin main. That made branch-based prereleases impossible even when the requested release type was explicitly a prerelease.

Verification

• git diff --check --cached
• Ruby YAML parse for .github/workflows/release.yml
• local shell harness covering allowed and rejected release-ref combinations

actionlint was not available in the local environment.

Disclaimer: Experimental PR review

Greptile Summary

This PR updates the release workflow to permit prerelease version bumps (prepatch, preminor, premajor) from non-main branches while keeping official releases restricted to main, and fixes the version-commit push to target the triggering branch dynamically instead of hardcoding main.

• Branch guard reworked: the monolithic refs/heads/main check is replaced with a two-stage shell conditional — main exits early allowing all types, non-main branches are gated to prerelease bump types with a mandatory non-empty prerelease_type.
• Push target corrected: git push origin main is replaced with git push origin "HEAD:${GITHUB_REF_NAME}", so the version bump commit lands on the correct branch regardless of where the workflow was triggered.
• Minor inconsistency: the early exit 0 for main skips the prerelease_type presence check in the verify step for prerelease bump types, but the downstream "Calculate new version" step enforces the same constraint, so no release can proceed without a valid prerelease_type when needed.

Confidence Score: 4/5

Safe to merge — the workflow logic correctly enforces branch and prerelease-type constraints, and the push target change eliminates the hardcoded main ref.

The branch guard and push target changes are correct. The only nuance is that the exit 0 shortcut for main skips the prerelease_type presence check in the verify step when doing a prerelease bump, but the Calculate new version step independently enforces the same constraint, so the overall workflow behavior is unaffected.

.github/workflows/release.yml — specifically the main early-exit path and how prerelease_type is validated across the two separate steps.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[workflow_dispatch triggered] --> B{GITHUB_REF_TYPE == 'branch'?}
    B -- No --> FAIL1[❌ Exit 1: must be branch ref]
    B -- Yes --> C{GITHUB_REF_NAME == 'main'?}
    C -- Yes --> D[✅ Exit 0: all release types allowed]
    C -- No --> E{inputs.version in prepatch / preminor / premajor?}
    E -- No --> FAIL2[❌ Exit 1: official releases restricted to main]
    E -- Yes --> F{inputs.prerelease_type is non-empty?}
    F -- No --> FAIL3[❌ Exit 1: branch releases must specify prerelease_type]
    F -- Yes --> G[✅ Pre-release branch release allowed]
    D & G --> H[Confirm major release check if major/premajor]
    H --> I[Checkout, configure git, compute version]
    I --> J[Build, verify, publish to PyPI]
    J --> K["git push origin HEAD:GITHUB_REF_NAME"]
    K --> L[git push tag]
    L --> M[GitHub Release + Slack notify]

Loading

_{Reviews (1): Last reviewed commit: "ci: allow prerelease branch releases" | Re-trigger Greptile}

[github-actions]

@claude review

[claude]

LGTM — small, well-scoped CI guard relaxation with proper input validation; the protected-branches environment gate still gates PyPI publishes.

Extended reasoning...

Overview

This PR modifies a single file (.github/workflows/release.yml) to allow prerelease bumps (prepatch/preminor/premajor) from non-main branches, while keeping official patch/minor/major releases pinned to main. It also changes the post-release git push target from a hardcoded main to HEAD:${GITHUB_REF_NAME} so the version commit lands on the triggering branch.

Security risks

The release workflow publishes to PyPI, which makes it security-sensitive in principle. However, the diff preserves the environment: protected branches gate, which still requires manual approval for the job to run. Inputs are passed via env: and dereferenced as shell variables (${INPUTS_VERSION}, ${INPUTS_PRERELEASE_TYPE}), avoiding YAML expression injection. GITHUB_REF_NAME is set by GitHub and the verify step rejects non-branch refs, so the new push target is a safe branch name.

Level of scrutiny

This is a CI/release pipeline change, which normally warrants higher scrutiny, but the change itself is small (~30 lines), purely mechanical, and the logic follows the existing pattern. The validation is straightforward (case statement plus an empty-check on prerelease_type), and the version input is a closed choice list, so the case fallthrough is exhaustive in practice.

Other factors

The bug hunting system found no issues, the description includes a verification harness, and the change directly fixes the documented contradiction between the early main guard and the workflow's prerelease support. No outstanding reviewer comments.

[hassiebp]

Operational follow-up: I added codex/* as an allowed branch deployment policy on the existing GitHub Environment named protected branches.

GitHub evaluates the job environment: gate before any workflow steps run, so the workflow-side prerelease guard alone cannot allow branch prereleases. Keeping the same environment preserves the current PyPI Trusted Publishing environment claim, while the workflow guard in this PR still prevents official patch/minor/major releases from non-main branches.