Publish Java libraries to GCS instead of Maven Central

Co-authored-by: Andrew <andrew@signal.org>
This commit is contained in:
Jordan Rose
2025-11-18 16:31:33 -08:00
parent 02d51454f2
commit 494495504f
6 changed files with 59 additions and 26 deletions

View File

@@ -1,4 +1,4 @@
name: Upload Java libraries to Sonatype
name: Upload Java libraries
run-name: ${{ github.workflow }} (${{ github.ref_name }})
on:
@@ -125,6 +125,11 @@ jobs:
publish:
name: Build for production and publish
permissions:
contents: read
# Needed for google-github-actions/auth.
id-token: write
runs-on: ubuntu-latest-8-cores
needs: [build, verify-rust]
@@ -175,12 +180,19 @@ jobs:
name: libsignal-server
path: java/server/build/libs/libsignal-server-*.jar
- id: gcp-auth
uses: google-github-actions/auth@55bd3a7c6e2ae7cf1877fd1ccb9d54c0503c457c # v2.1.2
if: ${{ !inputs.dry_run }}
with:
workload_identity_provider: 'projects/741367068918/locations/global/workloadIdentityPools/github/providers/github-actions'
service_account: 'github-actions@signal-build-artifacts.iam.gserviceaccount.com'
token_format: 'access_token'
- run: make publish_java
if: ${{ !inputs.dry_run }}
working-directory: java
env:
ORG_GRADLE_PROJECT_sonatypeUsername: ${{ secrets.SONATYPE_USER }}
ORG_GRADLE_PROJECT_sonatypePassword: ${{ secrets.SONATYPE_PASSWORD }}
CLOUDSDK_AUTH_ACCESS_TOKEN: ${{ steps.gcp-auth.outputs.access_token }}
ORG_GRADLE_PROJECT_signingKeyId: ${{ secrets.SIGNING_KEYID }}
ORG_GRADLE_PROJECT_signingPassword: ${{ secrets.SIGNING_PASSWORD }}
# ASCII-armored PGP secret key

View File

@@ -145,13 +145,25 @@ $ make
When exposing new APIs to Java, you will need to run `rust/bridge/jni/bin/gen_java_decl.py` in
addition to rebuilding. This requires installing the `cbindgen` Rust tool, as detailed above.
### Maven Central
### Use as a library
Signal publishes Java packages on [Maven Central](https://central.sonatype.org) for its own use,
under the names org.signal:libsignal-server, org.signal:libsignal-client, and
org.signal:libsignal-android. libsignal-client and libsignal-server contain native libraries for
Debian-flavored x86_64 Linux as well as Windows (x86_64) and macOS (x86_64 and arm64).
libsignal-android contains native libraries for armeabi-v7a, arm64-v8a, x86, and x86_64 Android.
Signal publishes Java packages for its own use, under the names org.signal:libsignal-server,
org.signal:libsignal-client, and org.signal:libsignal-android. libsignal-client and libsignal-server
contain native libraries for Debian-flavored x86_64 Linux as well as Windows (x86_64) and macOS
(x86_64 and arm64). libsignal-android contains native libraries for armeabi-v7a, arm64-v8a, x86, and
x86_64 Android. These are located in a Maven repository at
https://build-artifacts.signal.org/libraries/maven/; for use from Gradle, add the following to your
`repositories` block:
```
maven {
name = "SignalBuildArtifacts"
// The "uri()" part is only necessary for Kotlin Gradle; Groovy Gradle accepts a bare string here.
url = uri("https://build-artifacts.signal.org/libraries/maven/")
}
```
Older builds were published to [Maven Central](https://central.sonatype.org) instead.
When building for Android you need *both* libsignal-android and libsignal-client, but the Windows
and macOS libraries in libsignal-client won't automatically be excluded from your final app. You can

View File

@@ -56,9 +56,7 @@ git push <remote> HEAD:main <release tag, e.g. v0.x.y>
### Android and Server: Sonatype
In the signalapp/libsignal repository on GitHub, run the "Upload Java libraries to Sonatype" action on the tag you just made. Then go to [Maven Central][] and wait for the build to show up (it can take up to an hour).
[Maven Central]: https://central.sonatype.com/artifact/org.signal/libsignal-client/versions
In the signalapp/libsignal repository on GitHub, run the "Upload Java libraries" action on the tag you just made.
### Node: NPM

View File

@@ -1,3 +1,5 @@
v0.86.6
- Java artifacts are now published to build-artifacts.signal.org rather than Maven Central. See the README for further instructions.
- keytrans: Fall back to search-with-version if self-monitor returns unexpected versions.

View File

@@ -29,14 +29,13 @@ java_build: docker_image
publish_java: DOCKER_EXTRA = $(shell [ -L build ] && P=$$(readlink build) && echo -v $$P/:$$P )
publish_java: docker_image
$(DOCKER) run --rm --user $$(id -u):$$(id -g) \
-v `cd .. && pwd`/:/home/libsignal/src $(DOCKER_EXTRA) \
-e ORG_GRADLE_PROJECT_sonatypeUsername \
-e ORG_GRADLE_PROJECT_sonatypePassword \
-e ORG_GRADLE_PROJECT_signingKeyId \
-e ORG_GRADLE_PROJECT_signingPassword \
-e ORG_GRADLE_PROJECT_signingKey \
-e CLOUDSDK_AUTH_ACCESS_TOKEN \
-v `cd .. && pwd`/:/home/libsignal/src $(DOCKER_EXTRA) \
$(DOCKER_IMAGE) \
sh -c "cd src/java; ./gradlew $(GRADLE_OPTIONS) publish closeAndReleaseStagingRepositories $(CROSS_COMPILE_SERVER)"
sh -c "cd src/java; ./gradlew $(GRADLE_OPTIONS) publish $(CROSS_COMPILE_SERVER)"
# We could run these through Docker, but they would have the same result anyway.

View File

@@ -1,3 +1,4 @@
import org.gradle.api.publish.PublishingExtension
import org.jetbrains.kotlin.gradle.dsl.JvmTarget
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
@@ -5,7 +6,6 @@ plugins {
id "base"
id "signing"
id "com.diffplug.spotless" version "7.2.1"
id "io.github.gradle-nexus.publish-plugin" version "2.0.0"
id "org.jetbrains.kotlin.jvm" version "2.1.0" apply false
id "org.jetbrains.dokka" version "2.0.0" apply false
@@ -104,15 +104,25 @@ ext.setUpSigningKey = { signingExt ->
}
}
nexusPublishing {
repositories {
sonatype {
username = project.findProperty('sonatypeUsername') ?: ""
password = project.findProperty('sonatypePassword') ?: ""
// This is the recommended configuration from the README for the plugin we use, gradle-nexus/publish-plugin.
// The URLs are from https://central.sonatype.org/publish/publish-portal-ossrh-staging-api/#configuration
nexusUrl.set(uri("https://ossrh-staging-api.central.sonatype.com/service/local/"))
snapshotRepositoryUrl.set(uri("https://central.sonatype.com/repository/maven-snapshots/"))
subprojects { subproject ->
subproject.plugins.withId('maven-publish') {
subproject.extensions.configure(PublishingExtension) { publishing ->
publishing.repositories {
maven {
name = "SignalBuildArtifacts"
// We can't use Gradle's built-in GCS support with the way we authenticate
// GitHub Actions. Fortunately, GCS's REST APIs are basically just normal HTTP
// GET/PUT with an auth token, which is compatible with what Gradle will do.
url = subproject.uri("https://storage.googleapis.com/build-artifacts.signal.org/libraries/maven")
credentials(HttpHeaderCredentials) {
name = "Authorization"
value = "Bearer ${System.getenv("CLOUDSDK_AUTH_ACCESS_TOKEN") ?: ""}"
}
authentication {
header(HttpHeaderAuthentication)
}
}
}
}
}
}