fix: publish releases automatically to Maven Central - #44
Conversation
The release workflow passed `-DautoPublish=true -DwaitUntil=published`, but
the root POM binds the plugin through an explicit `<configuration>` block
referencing `${central.autoPublish}` and `${central.waitUntil}`. An explicit
plugin configuration takes precedence over the mojo's own user properties, so
both flags were silently ignored. The 0.1.0 deployment stopped at `VALIDATED`
and required manual publishing from the Sonatype portal.
Pass the properties the POM actually reads, and assert on the effective POM
during input validation so a future rename fails the release before anything
is uploaded rather than ten minutes later.
Widen the resolution window to 30 minutes as well: propagation to
repo1.maven.org took roughly 15 minutes for 0.1.0, over the previous
10-minute budget.
Co-Authored-By: Claude <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 39 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe release workflow validates Maven Central publishing settings before upload, uses the ChangesMaven Central release flow
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant ReleaseWorkflow
participant MavenCentralPlugin
participant CentralRepository
participant ReleaseChecker
ReleaseWorkflow->>MavenCentralPlugin: Deploy with central.autoPublish and central.waitUntil
MavenCentralPlugin->>CentralRepository: Publish release artifacts
ReleaseWorkflow->>ReleaseChecker: Check expected artifact payloads
ReleaseChecker->>CentralRepository: Send timed HEAD requests
CentralRepository-->>ReleaseChecker: Return payload availability
ReleaseChecker-->>ReleaseWorkflow: Return resolution status
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 187-193: Update the release artifact availability check in
.github/workflows/release.yml#L157-L193 to HEAD each expected artifact using its
actual filename and require every published file, including JARs and POMs, to
resolve before treating the release as complete; revise the timeout messages and
rerun guidance there to describe all expected files rather than only Maven
Central POM resolution. Update CONTRIBUTING.md#L173-L176 to match this
all-artifacts-resolvable rerun condition.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 2a63f27c-044a-49b7-b495-5bd152f13d4d
📒 Files selected for processing (2)
.github/workflows/release.ymlCONTRIBUTING.md
The Central availability check only requested the `.pom` of each entry in `config/release/public-artifacts.txt`, ignoring the packaging column. A release whose POMs had propagated but whose jars had not would satisfy the check, so a re-run would skip the deploy and freeze an incomplete release — the one path that cannot be recovered by re-running. Extract the check into `scripts/check-central-release.sh` and assert the same payload set that `verify-central-bundle.sh` already asserts locally: each POM, plus the main, sources, and javadoc jars for `jar` packaging. Both the deploy guard and the resolution wait now share it, so they cannot drift apart. Co-Authored-By: Claude <noreply@anthropic.com>
|
Addressed in d3100e8 — the finding is valid.
The consequence is worse than a premature success: the POM-only check also gates the deploy skip. A release whose POMs had propagated but whose jars had not would satisfy it, so a re-run would skip the deploy and freeze the incomplete release — the one failure mode a re-run cannot recover from. Extracted into Verified against the live repository: And the partial-propagation case you described, against a local repository serving only the POMs:
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/check-central-release.sh`:
- Around line 16-23: Update the curl status handling in check-central-release.sh
to distinguish a genuine 404/missing artifact from Central, DNS/TLS, timeout,
and other transport or server failures. Return the existing “not published”
status only for 404 responses; propagate or return a distinct failure status for
all other errors so release.yml cannot trigger deploy during a Central outage.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 39e23992-e0b3-4111-a328-504775c0e7f1
📒 Files selected for processing (3)
.github/workflows/release.ymlCONTRIBUTING.mdscripts/check-central-release.sh
🚧 Files skipped from review as they are similar to previous changes (2)
- CONTRIBUTING.md
- .github/workflows/release.yml
The availability check discarded curl's status, so a DNS failure, a timeout, or a 5xx from Maven Central was indistinguishable from a 404. The deploy guard would then read "unreachable" as "not published" and redeploy a version that may already exist. Separate the two: exit 1 means Central answered and something is absent, exit 2 means Central could not be questioned. The deploy guard refuses to publish on 2 rather than guessing, while the resolution loop retries it — that loop only waits, so an unreachable Central is just another retry there. Co-Authored-By: Claude <noreply@anthropic.com>
|
Addressed in 53a910b — this one is valid too, and the failure mode is the dangerous direction.
The check now separates the two outcomes:
The two callers deliberately differ on
Verified all four states: And the deploy guard's decision for each:
|
fix: publish releases automatically to Maven Central
1 participant
Context
The 0.1.0 release run (30162233461) failed at
Wait for Maven Central resolution. The deployment had to be published by hand from the Sonatype portal.The publishing step logged
Deployment will require manual publishingandWaiting until Deployment ... is validated, despite the workflow passing-DautoPublish=true -DwaitUntil=published. The root POM binds the plugin through an explicit<configuration>:An explicit plugin
<configuration>takes precedence over the mojo's own${autoPublish}/${waitUntil}user properties, so both CLI flags were silently ignored. The deployment stopped atVALIDATED, and the next step spent its whole 10-minute budget waiting for a publication that had never been triggered.Changes
-Dcentral.autoPublish=true -Dcentral.waitUntil=published, the properties the POM actually reads. Thecentral.*indirection is kept on purpose — the safe defaults (false/validated) protect local builds, and only the release workflow opts in.autoPublishresolves totrueandwaitUntiltopublished. This would have failed the release before the upload instead of ten minutes after it, and guards against a future property rename.repo1.maven.orgtook ~15 minutes for 0.1.0, over the previous budget. The failure message now points at the deployments page and at the re-run procedure.gh run rerun <id> --failedover a fresh dispatch when resuming a failed release — a re-run keeps the original commit, so the signed tag still points at the code that produced the published artifacts.pom.xmlis unchanged: the indirection is correct, the caller was wrong.Verification
The diagnosis is proven by a positive/negative pair on the effective POM:
The second block is what the workflow was doing until now.
actionlintpasses on the modified workflow.0.1.0 itself was finalized separately by re-running the failed job: the signed tag
0.1.0now points at4aa373d(GPG signature verified), the GitHub Release is published, and the release-smoke consumer builds againstrepo1.maven.org. The end-to-end effect of this fix can only be confirmed on the next release.🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Documentation