Skip to content

fix(android): fail the release when a central deployment does not validate - #651

Merged
andiwand merged 2 commits into
mainfrom
fix/android-await-central-validation
Aug 2, 2026
Merged

fix(android): fail the release when a central deployment does not validate#651
andiwand merged 2 commits into
mainfrom
fix/android-await-central-validation

Conversation

@andiwand

@andiwand andiwand commented Aug 2, 2026

Copy link
Copy Markdown
Member

publishToMavenCentral uploads the bundle and exits without waiting:

Uploaded bundle to Central Portal as USER_MANAGED, deployment id: 112cd9a1-...
Skipping deployment validation!
BUILD SUCCESSFUL in 10s

Exit 0 whatever the portal then makes of it. A release that uploaded something central rejects looks exactly like one that worked — every android test publish during the maven central bring-up had to be checked by hand in the portal UI.

The maven jar never had this problem: the sonatype plugin blocks and logs has been validated, so maven.yml fails loudly. Only android.yml was silent.

Why not just ask the plugin

publishToMavenCentral(false, DeploymentValidation.VALIDATED) looks like the fix and does nothing. The plugin only wires its validation task in when automaticRelease is true:

if (task.name.endsWith("ToMavenCentralRepository")) {
    task.dependsOn(prepareTask)
    if (automaticRelease)                    // <- the guard
        task.dependsOn(enableAutomaticTask)  // <- carries the DeploymentValidation
}

That was the first version of this PR, caught in review and then confirmed on a real publish — the log above is from that run, with the enum set.

Turning automaticRelease on would validate, but it also releases the deployment. Central never forgets a version, so pressing that button stays a human's job; that was the point of autoPublish = false and it does not change here.

So the workflow polls

.github/scripts/await-central-validation.sh reads the deployment id out of the gradle log and polls /api/v1/publisher/status until the portal reports VALIDATED, failing the job on FAILED (with the portal's own error text) or on a 10 minute ceiling.

The publish step also gains shell: bash, for the pipefail that Actions' default bash -e does not set — otherwise tee's exit code would hide a failing gradle, which is the same class of silent success this PR is about.

…idate

`publishToMavenCentral()` uploads the bundle, prints "Skipping deployment
validation!" and exits 0 whatever the portal then makes of it. A release that
uploaded something central rejects looked exactly like one that worked, and the
only way to tell them apart was opening the portal by hand.

The plugin can wait; it just does not by default. `DeploymentValidation.VALIDATED`
polls until the portal has validated the deployment and fails the build if it
does not, which is what the maven jar's path has always done - the sonatype
plugin there blocks and logs "has been validated".

Still USER_MANAGED: validating is not releasing, so a human still presses the
button and a bad artifact is still recallable.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lqc6gWzBBnoqvdaQ9HPoEa

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d3df0cfe61

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread android/build.gradle.kts
…idate

`publishToMavenCentral` uploads the bundle, prints "Skipping deployment
validation!" and exits 0 whatever the portal then makes of it. A release that
uploaded something central rejects looked exactly like one that worked, and the
only way to tell them apart was opening the portal by hand.

The plugin cannot help here: it wires its validation task in only when
`automaticRelease` is on, and that also releases the deployment - which is
deliberately a human's job, since central never forgets a version. So the
workflow polls the portal itself, the way the maven jar gets for free from the
sonatype plugin.

The publish step gains `shell: bash` for its pipefail, without which tee's exit
code would hide a failing gradle - the same class of silent success this is
about.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lqc6gWzBBnoqvdaQ9HPoEa
@andiwand
andiwand merged commit 2a25bf0 into main Aug 2, 2026
28 of 35 checks passed
@andiwand
andiwand deleted the fix/android-await-central-validation branch August 2, 2026 12:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant