Automate release publishing via GitHub Actions

[runningcode]

Summary

• Add gradle-release.yml workflow triggered on tag push (v*) that publishes to Maven Central, Gradle Plugin Portal, and creates a GitHub Release with auto-generated notes
• Simplify CI snapshot publishing from 2 steps with 3 separate publish tasks to a single publishToMavenCentral task
• Switch secret passing from -P CLI flags to ORG_GRADLE_PROJECT_* env vars
• Update docs/releasing.md to reflect the new automated flow

Required secrets

These need to be added to the repo settings (if not already present):

• GPG_SIGNING_KEY — ASCII-armored GPG private key
• GPG_SIGNING_KEY_ID — last 8 chars of key ID
• GPG_SIGNING_KEY_PASSWORD — key passphrase
• GRADLE_PUBLISH_KEY — Gradle Plugin Portal API key
• GRADLE_PUBLISH_SECRET — Gradle Plugin Portal API secret

🤖 Generated with Claude Code

[YotamNordman]

Code Review

Summary: Automates release publishing via GitHub Actions. New gradle-release.yml workflow triggered on tag push (v*) publishes to Maven Central, Gradle Plugin Portal, and creates GitHub Release with auto-generated notes. Consolidates 2 separate gradle publish tasks into 1. Switches from -P CLI flags to ORG_GRADLE_PROJECT_* env vars for secrets.

✅ Strengths

1. Smart release automation:

   • New workflow triggered on push with tag v* pattern
   • Single workflow handles: Maven Central, Gradle Plugin Portal, GitHub Release
   • Eliminates manual release steps (operator error risk removed)
   • Clear trigger: tag push → automated releases

2. Proper secret handling:

   • Switches from -P CLI flags (visible in logs) to ORG_GRADLE_PROJECT_* env vars
   • Gradle natively reads env vars; secrets masked in logs
   • Required secrets clearly documented in PR body
   • GPG signing, Sonatype username/password, Gradle Portal keys all listed

3. Simplified CI snapshot publishing:

   • Old: 2 separate gradle commands with individual flag syntax
   • New: Single publishToMavenCentral command
   • Reduced complexity, fewer failure points
   • Added --no-configuration-cache for correctness

4. GitHub Release automation:

   • Uses gh release create with --generate-notes
   • Auto-generates notes from commit history
   • No manual release notes needed
   • Proper permissions: contents: write for release creation

5. Documentation updates:

   • docs/releasing.md updated to reflect new workflow
   • Removed manual publish steps (now automated)
   • Maven Central URL link fixed (oss.sonatype → central.sonatype)
   • Clear statement: "Pushing tag triggers release workflow"

⚠️ Issues & Concerns

1. Mergeable state: unstable:

   • CI or status checks not passing
   • Blocks merge until resolved

2. Missing workflow_dispatch security:

   • Workflow has workflow_dispatch trigger (can be run manually)
   • No job-level approval/restrictions
   • Anyone with repo access can manually trigger release via web UI
   • Should add environment or require approval for manual triggers

3. No changelog file in release automation:

   • Generates release notes from commits (good!)
   • But changelog.md has duplicate "0.20.0" entry (error?)
   • Manual steps still say "Release to Maven Central → Click Publish" — is this still needed?
   • Unclear if Maven Central requires manual approval step or if workflow auto-promotes

4. Version bumping not automated:

   • PR bumps version 0.19.1-SNAPSHOT → 0.20.0
   • Next version still manual (mkdocs.yml updated to 0.20.1)
   • Should either: fully automate version bumping or clearly document manual step
   • Risk: human might forget to update version, causing duplicate releases

5. Gradle Plugin Portal key handling:

   • Uses GRADLE_PUBLISH_KEY/GRADLE_PUBLISH_SECRET as env vars
   • But these are custom names (not ORG_GRADLE_PROJECT_* pattern)
   • Gradle reads these natively, but inconsistent with other secret handling
   • Should document where these env var names come from (Gradle plugin spec?)

6. Incomplete secret setup:

   • PR lists required secrets but doesn't show how to add them
   • No instructions for: GPG key export format, Gradle Portal API key generation
   • Operator needs to know: GPG_SIGNING_KEY must be ASCII-armored
   • Consider: link to Gradle docs or Sonatype docs for setup steps

🔍 Minor Issues

• Changelog duplicate: "0.20.0" appears twice with identical text (should have unique changes)
• --no-configuration-cache added to snapshot publish but rationale not documented (is it needed?)
• 12 commits for relatively small change (suggests iteration; consider squashing in future)
• Workflow uses gradle/actions/setup-gradle@v5 — should verify this is latest/stable

Verdict

⏸️ BLOCKED | Score: 7/10

Blockers:

1. Fix mergeable_state (resolve CI/status checks)
2. Fix changelog duplicate "0.20.0" entry (one should be removed or have unique content)
3. Clarify Maven Central manual approval step: does workflow auto-promote or does operator need to click "Publish"?
4. Document workflow_dispatch restrictions (who can manually trigger release?)

Nice-to-have:

1. Add workflow approval/environment requirement for workflow_dispatch trigger
2. Automate version bumping (consider version.gradle or gradle.properties property)
3. Document required secret setup: GPG key export, API key generation links
4. Explain --no-configuration-cache rationale
5. Document Maven Central approval step (auto vs manual)

Summary: Well-designed release automation removing manual error-prone steps. Workflow structure is solid, secret handling improved. Main concerns are: (1) CI blocker, (2) changelog duplicate, (3) unclear if Maven Central approval is automated or manual, (4) version bumping still manual. Once CI passes and release process is clarified (especially Maven Central approval), this is merge-ready.