We deploy Conscrypt to Maven Central under the following systems:
Other systems may also work, but we haven't verified them.
Each build environment for a particular release MUST use the same version of BoringSSL. This is necessary in order to maintain consistency across platforms as well as to allow the Uber JAR to specify a single version for BoringSSL in its MANIFEST.MF.
When deploying, it may be useful to begin with Linux (via Docker), taking note of the BoringSSL version used, and then deploying Mac and Windows with that version via:
boringssl$ git checkout <commit id>
If you haven't deployed artifacts to Maven Central before, you need to setup your OSSRH (OSS Repository Hosting) account and signing keys.
gpg --keyserver pgp.mit.edu --send-key <key ID>).<your-home-directory>/.gradle/gradle.properties.# You need the signing properties only if you are making release deployment signing.keyId=<8-character-public-key-id> signing.password=<key-password> signing.secretKeyRingFile=<your-home-directory>/.gnupg/secring.gpg ossrhUsername=<ossrh-username> ossrhPassword=<ossrh-password> checkstyle.ignoreFailures=false
The first step in the release process is to create a release branch, bump versions, and create a tag for the release. Our release branches follow the naming convention of v<major>.<minor>.x, while the tags include the patch version v<major>.<minor>.<patch>. For example, the same branch v1.0.x would be used to create all v1.0 tags (e.g. v1.0.0, v1.0.1).
Create the release branch and push it to GitHub:
$ git checkout -b 1.0.x master $ git push upstream 1.0.x
Update master branch to the next minor snapshot (e.g. 1.1.0-SNAPSHOT) and update references to the version in README.md.
$ git checkout -b bump-version master # Change version to next minor (and keep -SNAPSHOT) $ ${EDITOR:-nano -w} build.gradle # Bump documented versions. $ ${EDITOR:-nano -w} README.md $ ./gradlew build $ git commit -a -m "Start 1.1.0 development cycle"
Go through PR review and push the master branch to GitHub:
$ git checkout master $ git merge --ff-only bump-version $ git push upstream master
In the release branch, remove “-SNAPSHOT” for the next release version (e.g. ‘1.0.0’) and update references to the version in README.md. Commit the result and make a tag:
$ git checkout 1.0.x # Change version to remove -SNAPSHOT $ ${EDITOR:-nano -w} build.gradle # Bump documented versions. $ ${EDITOR:-nano -w} README.md $ git commit -a -m "Change version to 1.0.0" $ git tag -a 1.0.0 -m "Version 1.0.0"
In the release branch, bump to the next patch snapshot version (e.g. 1.0.1-SNAPSHOT). Commit the result:
# Change version to next patch and add -SNAPSHOT $ ${EDITOR:-nano -w} build.gradle $ ./gradlew build $ git commit -a -m "Bump version to 1.0.1-SNAPSHOT"
Go through PR review and push the release tag and updated release branch to GitHub:
$ git push upstream 1.0.0 $ git push upstream 1.0.x
The deployment for Linux uses Docker running CentOS 6.6 in order to ensure that we have a consistent deployment environment on Linux. You'll first need to install Docker if not already installed on your system.
From the conscrypt source directory:
conscrypt$ docker build -t conscrypt-deploy .
Start a Docker container that has the deploy environment set up for you. The Conscrypt source is cloned into /conscrypt.
$ docker run -it --rm=true conscrypt-deploy
Note that the container will be deleted after you exit. Any changes you have made (e.g., copied configuration files) will be lost. If you want to keep the container, remove --rm=true from the command line.
Next, you'll need to copy your OSSRH credentials and GnuPG keys to your docker container. In Docker:
# mkdir /root/.gradle
Find the container ID in your bash prompt, which is shown as [root@<container-ID> ...]. In host:
$ docker cp ~/.gnupg <container-ID>:/root/ $ docker cp ~/.gradle/gradle.properties <container-ID>:/root/.gradle/
You'll also need to update signing.secretKeyRingFile in /root/.gradle/gradle.properties to point to /root/.gnupg/secring.gpg.
For Windows and Mac, see BUILDING for instructions for setting up the build environment.
We currently distribute the following OSes and architectures:
| OS | x86_32 | x86_64 |
|---|---|---|
| Linux | X | |
| Mac | X | |
| Windows | X | X |
Deployment to Maven Central (or the snapshot repo) is a two-step process. The only artifact that is platform-specific is codegen, so we only need to deploy the other jars once. So the first deployment is for all of the artifacts from one of the selected OS/architectures. After that, we then deploy the codegen artifacts for the remaining OS/architectures.
NOTE: Before building/deploying, be sure to switch to the appropriate branch or tag in the Conscrypt source directory.
As stated above, this only needs to be done once for one of the selected OS/architectures. The following command will build the whole project and upload it to Maven Central. Parallel building is not safe during uploadArchives.
Linux/Mac:
conscrypt$ ./gradlew build && ./gradlew -Dorg.gradle.parallel=false uploadArchives
Windows:
C:\conscrypt>gradlew build && gradlew -Dorg.gradle.parallel=false uploadArchives
If the version has the -SNAPSHOT suffix, the artifacts will automatically go to the snapshot repository. Otherwise it's a release deployment and the artifacts will go to a freshly created staging repository.
The previous step will only deploy the artifacts for the OS you run on it and the architecture of your JVM. For a fully fledged deployment, you will need to deploy for each supported OS/architecture.
When deploying a Release, the first deployment will create a new staging repository. You'll need to look up the ID in the OSSRH UI (usually in the form of orgconscrypt-*). Codegen deployment commands should include -PrepositoryId=<repository-id> in order to ensure that the artifacts are pushed to the same staging repository.
Linux/Mac:
conscrypt$ ./gradlew build && ./gradlew -Dorg.gradle.parallel=false \ conscrypt-openjdk:uploadArchives -PrepositoryId=<repository-id>
Windows:
C:\conscrypt>gradlew build && gradlew -Dorg.gradle.parallel=false ^ conscrypt-openjdk:uploadArchives -PrepositoryId=<repository-id>
Now finish Releasing on Maven Central.
Once all of the native JARs appear on Maven Central, you can build and deploy the Uber JAR that contains all of them.
Linux/Mac:
conscrypt$ ./gradlew conscrypt-openjdk-uber:build \ -Dorg.conscrypt.openjdk.buildUberJar=true conscrypt$ ./gradlew conscrypt-openjdk-uber:uploadArchives \ -Dorg.gradle.parallel=false \ -Dorg.conscrypt.openjdk.buildUberJar=true
Windows:
C:\conscrypt>gradlew conscrypt-openjdk-uber:build ^ -Dorg.conscrypt.openjdk.buildUberJar=true C:\conscrypt>gradlew conscrypt-openjdk-uber:uploadArchives ^ -Dorg.gradle.parallel=false ^ -Dorg.conscrypt.openjdk.buildUberJar=true
This will create a new staging repository, so you'll need to close and release the repository via the OSSRH UI, as you did in the previous step.
Once all of the artifacts have been pushed to the staging repository, the repository must first be closed, which will trigger several sanity checks on the repository. If this completes successfully, the repository can then be released, which will begin the process of pushing the new artifacts to Maven Central (the staging repository will be destroyed in the process). You can see the complete process for releasing to Maven Central on the [OSSRH site] (http://central.sonatype.org/pages/releasing-the-deployment.html).
Finally, document and publicize the release.
conscrypt@googlegroups.com). The title should be something that clearly identifies the release (e.g.Conscrypt <tag> Released).