ci+docs(release): disable broken auto-publish + add Central Portal runbook - #17
Merged
Merged
Conversation
The `Build library with gradle` step (which ran `make maven`) would have failed on every tag push since the OSSRH sunset: - `make maven-legacy` uploads to https://s01.oss.sonatype.org, which Sonatype shut down on 2025-06-30. - `make maven-cbor` (vanniktech plugin's `publishAndReleaseToMavenCentral` task) needs a GPG private key and Central Portal user token, neither wired up in CI yet. 1.0.15 was published manually from the maintainer workstation. Replace the build step with a no-op `echo` notice that points the next person at planning/canonical-cbor/release-checklist.md and lists exactly what secrets / actions need to be added to re-enable CI auto-publish. Keep the JDK 17 / Gradle 9 / cache steps in place so the workflow stays ready for the eventual CI rewire — the unused steps cost ~30s per tag push, vastly cheaper than someone wading through git history later trying to remember how the toolchain was set up. Slack notification + GitHub Release creation still happen on tag push, just without the auto-publish bit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Code Coverage
|
zhuzhuyule
added a commit
that referenced
this pull request
Apr 29, 2026
The previous checklist was written when paper still had OSSRH JIRA credentials and the Sonatype legacy staging API at s01.oss.sonatype.org was alive. Both of those are now gone (paper left; OSSRH sunset 2025-06-30), and the actual 1.0.15 release that just shipped used a different toolchain entirely: - Sonatype Central Portal (https://central.sonatype.com), not OSSRH - vanniktech maven-publish plugin's `publishAndReleaseToMavenCentral`, not custom `publishing { repositories { ... } }` blocks - GPG via `signing.useGpgCmd()` reading the maintainer's local GnuPG keybox (no secring.gpg, no in-memory armored key in gradle.properties) - Central Portal user token (`mavenCentralUsername` / `Password` in gradle.properties), not JIRA accounts Rewrite end-to-end so the next maintainer can follow it without the team-tribal-knowledge gap that nearly cost us the namespace this release. Calls out: - One-time per-machine setup (pinentry-mac, GPG keygen + keyserver push + email verification, gradle.properties) - Why @arcblock.io email matters (paper's personal Gmail was the namespace-loss root cause) - publishToMavenLocal smoke test as the gating step before real publish - Central Portal Deployments UI state machine (PENDING → VALIDATING → VALIDATED → PUBLISHING → PUBLISHED) - Tag push expectations after issue #18 lands (currently the workflow is intentionally disabled — see PR #17) - Rollback caveat (Central Portal immutability) - Pointer to issue #18 for the CI auto-publish work that should eventually obsolete most of this manual flow Section numbering shifted: pre-release verification stays the entry point, but bump-version is now its own numbered step (was inline) and the old "Move modules into root build" optional step is dropped because it's not relevant to ongoing releases. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
zhuzhuyule
changed the title
Code Coverage
|
The original `release-checklist.md` was written when paper still had
OSSRH JIRA credentials and `s01.oss.sonatype.org` was the canonical
staging API. Both of those are now gone (paper left; OSSRH sunset
2025-06-30), so following that file end-to-end is no longer possible.
Rather than rewriting it in-place (which would erase the historical
record of how the SDK *used* to ship), introduce a parallel
`manual-release-runbook.md` that documents the actual flow used to
publish 1.0.15 today:
- One-time per-machine setup: pinentry-mac install, GPG keygen with
@arcblock.io email, push public key to keys.openpgp.org + email
verification, Central Portal user token, gradle.properties
- Pre-release verification (per-module test suites)
- publishToMavenLocal smoke test as the gating step
- Real publish via vanniktech's `make maven-cbor` ->
`publishAndReleaseToMavenCentral`
- Sonatype Deployments state machine
(PENDING -> VALIDATING -> VALIDATED -> PUBLISHING -> PUBLISHED)
- Maven Central artifact verification (curl probe)
- Tag push + GitHub Release / Slack notification path
- Downstream consumer bump (arc-wallet-android config.gradle)
- Rollback caveat (Central Portal immutability)
- Pointer to issue #18 for the CI auto-publish work that should
eventually obsolete most of this manual flow
Calls out explicitly the @arcblock.io-email-not-personal-Gmail rule
(paper's personal Gmail was the namespace-loss root cause).
The original `release-checklist.md` is kept untouched; it serves as
the historical record of the OSSRH-era procedure.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
zhuzhuyule
force-pushed
the
ci/neutralize-broken-auto-publish
branch
from
April 29, 2026 12:32
255c9cf to
015fb9e
Compare
zhuzhuyule
changed the title
Code Coverage
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
After the 1.0.15 release shipped successfully via the new Sonatype Central Portal flow today, two release-infrastructure cleanup items needed to happen:
release.yml would fail on every tag push since the OSSRH sunset (2025-06-30) — both halves of
make mavenare broken on a freshubuntu-latestrunner. Pushing thev1.0.15tag would produce a red ❌ even though the artifacts are already on Maven Central.planning/canonical-cbor/release-checklist.mdwas written for paper's OSSRH-era flow. It referencess01.oss.sonatype.org(sunset), JIRA credentials (no longer how Central Portal works), and assumes the publisher already has secring.gpg + an in-memory armored key — none of which match reality after the namespace migration to Central Portal. Following it end-to-end is no longer possible.What changes
.github/workflows/release.ymlReplace the broken
make mavenstep with a no-opechonotice. Slack notification + GitHub Release creation still run on tag push — those parts work fine. The JDK 17 / Gradle 9 / cache steps stay so the workflow is ready for the eventual CI rewire (see issue #18).planning/canonical-cbor/manual-release-runbook.md(new file)Adds a parallel runbook for the active Central Portal flow without erasing the original OSSRH-era checklist. Covers:
~/.gradle/gradle.propertiesmake maven-cbor→publishAndReleaseToMavenCentralplanning/canonical-cbor/release-checklist.md(unchanged)Preserved as the historical record of the OSSRH-era procedure. Not deleted, not modified.
Test plan
manual-release-runbook.mdand confirms it matches the actual flow we just executed for 1.0.15release.ymlYAML is syntactically validv1.0.15tag — CI run should be all green: skip step, create release, slack notify, gradle cache cleanupRelated
🤖 Generated with Claude Code