Skip to content

release: Migrate artifacts publishing from legacy OSSRH to Central Portal #12156

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jun 24, 2025

Conversation

shivaspeaks
Copy link
Member

We will be using Publish By Using the Portal OSSRH Staging API to have minimal changes in our release process.

We will generate new token by following the Generating a Portal Token for Publishing documentation that gives us Central Portal Token through UI and update the same in our GCS file sonatype-upload with new token. We will also update our g3 docs defining #auto-releasing-using-kokoro and #how-the-kokoro-release-job-is-structured as required. (I'm not adding links because it's Google internal.)

Copy link
Member

@ejona86 ejona86 left a comment

Choose a reason for hiding this comment

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

We should discuss the process for rolling this out, whether we are able to do any testing, etc.

curl --fail-with-body -X POST \
-H "Authorization: Bearer ${BEARER_TOKEN}" \
-H "Content-Type: application/json" \
"${MANUAL_API_URL}/upload/repository/${REPOID}?publishing_type=automatic"
Copy link
Member

Choose a reason for hiding this comment

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

MANUAL_API_URL is undefined

BEARER_TOKEN=$(echo -n "$USERPASS" | base64)

curl --fail-with-body -X POST \
-H "Authorization: Bearer ${BEARER_TOKEN}" \
Copy link
Member

Choose a reason for hiding this comment

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

I know the documentation said it is Bearer, but I'm suspicious it is actually Basic. You can see in the old API we passed -u to curl, which does HTTP basic (because servers rarely request HTTP digest these days). The same for Gradle; it looks configured for Basic. The base64 scheme it talks about is actually Basic, except they replaced the Authorization header prefix with Bearer.

Copy link
Member Author

Choose a reason for hiding this comment

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

I found more on how we were using -u earlier, there it is explicitly shown the usage in the doc, on page 172. No mention of bearer in their the documentation. Why would they say in the new central portal! Thats unconventional by Sonatype.

Copy link
Member

Choose a reason for hiding this comment

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

I'm suspicious it was actually a typo or someone less familiar didn't realize the difference it was actually Basic. Bearer is very common, but for user:pass authentication should generally be Basic. They both start with B; someone might not realize the error.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah could be.
Even I found couple of typos at places in their migration documentations.

@shivaspeaks shivaspeaks merged commit f99b2aa into grpc:master Jun 24, 2025
16 checks passed
@shivaspeaks shivaspeaks deleted the OSSRH-sunset branch June 24, 2025 04:42
jdcormie pushed a commit to jdcormie/grpc-java that referenced this pull request Jun 27, 2025
svc-squareup-copybara pushed a commit to cashapp/misk that referenced this pull request Jul 29, 2025
| Package | Type | Package file | Manager | Update | Change |
|---|---|---|---|---|---|
| [io.grpc:grpc-stub](https://github.com/grpc/grpc-java) | dependencies
| misk/gradle/libs.versions.toml | gradle | minor | `1.73.0` -> `1.74.0`
|
| [io.grpc:grpc-protobuf](https://github.com/grpc/grpc-java) |
dependencies | misk/gradle/libs.versions.toml | gradle | minor |
`1.73.0` -> `1.74.0` |
| [io.grpc:grpc-netty](https://github.com/grpc/grpc-java) | dependencies
| misk/gradle/libs.versions.toml | gradle | minor | `1.73.0` -> `1.74.0`
|
| [io.grpc:protoc-gen-grpc-java](https://github.com/grpc/grpc-java) |
dependencies | misk/gradle/libs.versions.toml | gradle | minor |
`1.73.0` -> `1.74.0` |
| [io.grpc:grpc-bom](https://github.com/grpc/grpc-java) | dependencies |
misk/gradle/libs.versions.toml | gradle | minor | `1.73.0` -> `1.74.0` |
| [io.grpc:grpc-api](https://github.com/grpc/grpc-java) | dependencies |
misk/gradle/libs.versions.toml | gradle | minor | `1.73.0` -> `1.74.0` |
|
[com.google.cloud:google-cloud-logging](https://github.com/googleapis/java-logging)
| dependencies | misk/gradle/libs.versions.toml | gradle | patch |
`3.23.0` -> `3.23.1` |
| [software.amazon.awssdk:aws-core](https://aws.amazon.com/sdkforjava) |
dependencies | misk/gradle/libs.versions.toml | gradle | patch |
`2.32.9` -> `2.32.10` |
| [software.amazon.awssdk:bom](https://aws.amazon.com/sdkforjava) |
dependencies | misk/gradle/libs.versions.toml | gradle | patch |
`2.32.9` -> `2.32.10` |
| [software.amazon.awssdk:auth](https://aws.amazon.com/sdkforjava) |
dependencies | misk/gradle/libs.versions.toml | gradle | patch |
`2.32.9` -> `2.32.10` |

---

### Release Notes

<details>
<summary>grpc/grpc-java (io.grpc:grpc-stub)</summary>

### [`v1.74.0`](https://github.com/grpc/grpc-java/releases/tag/v1.74.0)

##### Behavior Changes

- compiler: Default to `@generated=omit`
([`f8700a1`](grpc/grpc-java@f8700a13a)). This
omits `javax.annotation.Generated` from the generated code and makes the
`org.apache.tomcat:annotations-api` compile-only dependency unnecessary
(README and examples changes forthcoming; we delayed those changes until
the release landed). You can use the option `@generated=javax` for the
previous behavior, but please also file an issue so we can develop
alternatives
- compiler: generate blocking v2 unary calls that throw StatusException
([#&#8203;12126](grpc/grpc-java#12126))
([`a16d655`](grpc/grpc-java@a16d65591)).
Previously, the new blocking stub API was identical to the older
blocking stub for unary RPCs and used the unchecked
`StatusRuntimeException`. However, feedback demonstrated it was
confusing to mix that with the checked `StatusException` in
`BlockingClientCall`. Now the new blocking stub uses StatusException
throughout. grpc-java continues to support the old generated code, but
the version of protoc-gen-grpc-java will dictate which API you see. If
you support multiple generated code versions, you can use the older
blocking v1 stub for unary RPCs

##### Bug Fixes

- netty: Fix a race that caused RPCs to hang on start when a GOAWAY was
received while the RPCs’ headers were being written to the OS
([`b04c673`](grpc/grpc-java@b04c673fd),
[`15c7573`](grpc/grpc-java@15c757398)). This
was a very old race, not a recent regression. All streams should now
properly fail instead of hanging, although in some cases they may be
transparently retried
- util: OutlierDetection should use nanoTime, not currentTimeMillis
([#&#8203;12110](grpc/grpc-java#12110))
([`1c43098`](grpc/grpc-java@1c4309899)).
Previously, changes in the wall time would impact its accounting
- xds: Don't allow hostnames in address field in EDS
([#&#8203;12123](grpc/grpc-java#12123))
([`482dc5c`](grpc/grpc-java@482dc5c1c)). Only
IP addresses were handled properly, and only IP addresses should be
handled per gRFC A27
- xds: In resource handling, call onError() for RDS and EDS NACKs
([#&#8203;12122](grpc/grpc-java#12122))
([`efe9ccc`](grpc/grpc-java@efe9ccc22)).
Previously the resource was NACKed, but gRPC would continue waiting for
the resource until a timeout was reached and claim the control plane
didn’t send the resource. Now it will fail quickly with an informative
error
- xds: Implement equals in RingHashConfig
([`a5eaa66`](grpc/grpc-java@a5eaa66cc)).
Previously all configuration refreshes were considered a new config,
which had the potential for causing unexpected inefficiency problems.
This was noticed by new code for gRFC A74 xDS Config Tears that is not
yet enabled, so there are no known problems that this caused
- LBs should avoid calling LBs after lb.shutdown()
([`1df2a33`](grpc/grpc-java@1df2a3305)). This
fixed pick\_first and ring\_hash behavior that could cause rare and
“random” races in parent load balancers like a `NullPointerException` in
`ClusterImplLoadBalancer.createSubchannel()`, which had a ring\_hash
child. This is most likely to help xDS, as it heavily uses hierarchical
LB policies

##### Improvements

- util: Deliver addresses in a random order to shuffle connection
creation ordering
([`f07eb47`](grpc/grpc-java@f07eb47ca)).
Previously, connections were created in-order (but non-blocking), so in
a fast network the first address could be more likely to connect first
given a "microsecond" headstart. That first connection then receives all
the buffered RPCs, which could cause temporary, but repeated, load
imbalances of the same backend when all clients receive the same list of
addresses in the same order. This has been seen in practice, but it is
unclear how often it happens. Shuffling has the potential to improve
load distribution of new clients when using round\_robin,
weighted\_round\_robin, and least\_request, which connect simultaneously
to multiple addresses
- core: Use lazy message formatting in checkState
([#&#8203;12144](grpc/grpc-java#12144))
([`26bd0ee`](grpc/grpc-java@26bd0eee4)). This
avoids the potential of unnecessarily formatting an exception as a
string when a subchannel fails to connect
- bazel: Migrate java\_grpc\_library to use DefaultInfo
([#&#8203;12148](grpc/grpc-java#12148))
([`6f69363`](grpc/grpc-java@6f69363d9)). This
adds compatibility for
`--incompatible_disable_target_default_provider_fields`
- binder: Rationalize
[@&#8203;ThreadSafe-ty](https://github.com/ThreadSafe-ty) inside
BinderTransport
([#&#8203;12130](grpc/grpc-java#12130))
([`c206428`](grpc/grpc-java@c20642874))
- binder: Cancel checkAuthorization() request if still pending upon
termination
([#&#8203;12167](grpc/grpc-java#12167))
([`30d40a6`](grpc/grpc-java@30d40a617))

##### Dependencies

- compiler: Upgrade Protobuf C++ to 22.5
([#&#8203;11961](grpc/grpc-java#11961))
([`46485c8`](grpc/grpc-java@46485c8b6)). This
is used by the pre-built protoc-gen-grpc-java plugin on Maven Central.
This should have no visible benefit, but gets us closer to upgrading to
Protobuf 27 which added edition 2023 support
- release: Migrate artifacts publishing changed from legacy OSSRH to
Central Portal
([#&#8203;12156](grpc/grpc-java#12156))
([`f99b2aa`](grpc/grpc-java@f99b2aaef)). We
aren’t aware of any visible changes to the results on Maven Central

</details>

<details>
<summary>googleapis/java-logging
(com.google.cloud:google-cloud-logging)</summary>

###
[`v3.23.1`](https://github.com/googleapis/java-logging/blob/HEAD/CHANGELOG.md#3231-2025-07-28)

##### Bug Fixes

- **deps:** Update the Java code generator (gapic-generator-java) to
2.60.2
([6a268f8](googleapis/java-logging@6a268f8))

##### Dependencies

- Update dependency com.google.cloud:sdk-platform-java-config to v3.50.2
([#&#8203;1834](googleapis/java-logging#1834))
([2e46f6e](googleapis/java-logging@2e46f6e))

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "after 6pm every weekday,before 2am
every weekday" in timezone Australia/Melbourne, Automerge - At any time
(no schedule defined).

🚦 **Automerge**: Enabled.

♻ **Rebasing**: Never, or you tick the rebase/retry checkbox.

👻 **Immortal**: This PR will be recreated if closed unmerged. Get
[config help](https://github.com/renovatebot/renovate/discussions) if
that's undesired.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

This PR has been generated by [Renovate
Bot](https://github.com/renovatebot/renovate).

GitOrigin-RevId: 135372e1ea07a30d50a7ad0c0665cc322791152a
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.

2 participants