Apollo Release

Run this skill when you want to execute the Apollo server formal release workflow in a controlled and resumable way.

Workflow Contract

• Work only in the current directory.
• Require current directory to be Apollo repository root (apollo + root pom.xml artifactId apollo).
• Require at least one git remote URL that normalizes to github.com/apolloconfig/apollo.
• Require explicit checkpoint confirmation before each external publish action.
• Persist progress in a state file under .git/ by default and support resume without repeating completed steps.

Command Entry

python3 scripts/release_flow.py run \
  --release-version X.Y.Z \
  --next-snapshot A.B.C-SNAPSHOT \
  --highlight-prs PR_ID_1,PR_ID_2,PR_ID_3 \
  [--state-file .git/apollo-release-state.json] \
  [--previous-tag vP.Q.R] \
  [--target-branch master] \
  [--confirm-checkpoint CHECKPOINT]

Use --target-branch 2.x for maintenance-line releases. If omitted, the flow targets master.

Supported checkpoints

• PUSH_RELEASE_PR
• CREATE_PRERELEASE
• TRIGGER_PACKAGE_WORKFLOW
• TRIGGER_DOCKER_WORKFLOW
• PROMOTE_RELEASE
• CREATE_ANNOUNCEMENT_DISCUSSION
• MANAGE_MILESTONES
• PUSH_POST_RELEASE_PR

If execution stops at a checkpoint, rerun with --confirm-checkpoint <NAME>.

Step Mapping (1~7)

1. Bump root pom.xml revision from X.Y.Z-SNAPSHOT to X.Y.Z, create release branch/commit/PR draft.
2. Wait for release PR merge, generate release note and announcement drafts from CHANGES.md, and create GitHub prerelease (vX.Y.Z, target --target-branch).
3. Trigger .github/workflows/release-packages.yml with JDK 8 build in GitHub Action; workflow uploads three zip packages and three sha1 assets to release.
4. Verify release assets exist in release page after package workflow succeeds.
5. Trigger .github/workflows/docker-publish.yml on --target-branch with release version and wait for completion.
6. Promote prerelease to official release, mark it as latest, and publish announcement discussion in Announcements.
7. Post-release housekeeping: bump to next SNAPSHOT, archive CHANGES.md, auto-manage milestones, and open post-release PR.

Scripts

• scripts/release_flow.py
  • Main orchestrator.
  • Handles preflight, checkpoint gating, workflow execution, release asset verification, milestone management, resume state, and final summary.
• scripts/release_notes_builder.py
  • Uses CHANGES.md as the source for What's Changed.
  • Merges GitHub generated notes for New Contributors and changelog link.
  • Builds Highlights only from user-selected PRs (--highlight-prs), then extracts practical usage hints from those PRs’ body/comments/docs changes.
  • Builds upgrade section from SQL delta inspection.
• scripts/github_discussion.py
  • Creates discussions via GraphQL using category name/slug.
• scripts/test_release_helpers.py
  • Unit tests for parser and helper behavior.

Referencee

• references/templates.md: Release note and announcement templates.

Operational Notes

• Prefer --dry-run first to validate step order and checkpoint prompts.
• Default state file lives under .git/ so preflight clean-tree checks are not polluted by the workflow state itself.
• Default release target is master; set --target-branch for release branches such as 2.x.
• Keep release operations on a clean working tree unless explicitly using --allow-dirty.
• Do not push, create PRs/releases, trigger workflows, edit milestones, or publish discussions without checkpoint confirmation.
• Build What's Changed from CHANGES.md entries, but render each PR item as ... by @<author> in <PR URL> so contributor mentions are preserved.
• Highlights PR list must be provided explicitly via --highlight-prs; do not auto-pick highlights.
• Always review generated Highlights draft and confirm wording before checkpoint CREATE_PRERELEASE.
• Resume runs with the same --target-branch; the state file now records and validates it.
• After a successful full run, the workflow auto-cleans generated temp artifacts such as the state file and .git draft files (release-notes, announcement, release-pr, post-release-pr). If announcement posting falls back to manual_required, temp artifacts are kept for manual recovery.