[manigandanparthasarathi-okta]

Summary

Restructures the SDK release so the release PR is merged into master before anything is tagged or published, matching the existing Android release guides and the shared Guardian SDK Release Guide (AA1 1156121307). CI stays the main actor. Jira: NAPP-173.

Changes

• New prepare-release.yml (manual, on master, version input): validates the version (X.Y.Z, higher than the latest tag, not on Maven Central, no tag or GitHub Release yet), creates release/X.Y.Z, sets .version and the README install line, drafts the CHANGELOG entry from the PRs merged since the previous tag, commits it as one GitHub-signed commit through the Git Data API, opens the "Release X.Y.Z" PR and approves the PR checks run that GitHub holds at "Approval required" for a PR opened by github-actions[bot], so the checks show on the PR (a dispatched pr.yml runs the tests but does not show on the PR). Re-runs are safe; once the release PR is merged and the version is not on Maven Central, it recreates the branch from master for a correction PR.
• Reworked release.yml: triggers on push to master and continues only when the commit is the squash merge of a release PR (so the run's ref is master, as a master-only environment policy expects); manual dispatch with version for re-runs, which releases the merge commit of the newest merged release/X.Y.Z PR (never master's head) and fails if there is none, so a release cannot skip Prepare release. Jobs: validate, test, then publish behind the maven-central-release approval gate. Publish creates a draft GitHub Release on the merge commit, uploads to Maven Central staging, then publishes the draft, which creates the tag. Promotion in the Portal stays manual.
• Corrections: a newer run for a version cancels older runs that have not started publishing, and publish refuses to run when a newer run for its version exists. If an earlier run already uploaded to staging, the new run stops and asks for that deployment to be dropped in the Portal, then a manual run with staging_dropped moves the Release and tag and uploads again (the upload does not report its deployment ID, so CI cannot drop it).
• Removed the post-publish CHANGELOG commit, the tag on the release branch and the auto PR to master. No more unsigned bot commits.

Not in this PR

The environment name: required reviewers currently sit on the release environment, while the workflow uses maven-central-release. That is being sorted out in OKTA-1296888 and will follow separately.

Testing

actionlint is clean on both workflows. Both workflows were exercised end to end on a personal fork (dummy secrets, so nothing could reach Maven Central; for the success path the upload step was stubbed in a fork-only commit). Results:

• Prepare release: rejects a non-master run, a malformed version, a version already on Central, a version not higher than the latest tag, an existing tag and an existing GitHub Release. A fresh run makes one Verified commit touching only .version, README and CHANGELOG, opens the PR and approves the held PR checks, which then show on the PR. A re-run with the PR open does nothing; after a closed PR it reuses the existing branch and opens a new PR; after a merge it recreates the branch from master for a correction PR whose diff holds only the fix. The CHANGELOG compare link uses the previous tag.
• Release: pushes that are not a release merge finish straight away; a manual run with no merged release PR, or on a non-master branch, fails; a hand-made release branch without the .version bump fails validation before the gate. A merged release PR waits at the gate and the master-only branch policy accepts the run. A manual run releases the reviewed merge commit, not master's head. A newer run cancels an older one waiting at the gate, and approving a stale run is refused by the newest-run guard. A failed upload leaves only the draft; a re-run reuses and repairs it. The success path publishes the draft and puts the tag on the merge commit with the CHANGELOG entry as the body. A re-run on the same commit only prints the promote notice. A correction after an upload stops with the drop-in-the-Portal error, and a manual run with staging_dropped moves the Release and tag to the new merge commit.

Two bugs found and fixed by this testing: a dispatched pr.yml does not show on the PR (now the held run is approved instead), and updating a draft Release without tag_name resets it to untagged-... so the re-run could not find it (the tag name is now always sent and the draft is also matched by title).

Still to do on the real repo: run Prepare release for the next patch version, merge, approve, let it upload to staging, then drop the deployment instead of promoting it.

🤖 Generated with Claude Code

[arunav-gandhi]

Added comments. Please check.