Skip to content

Latest commit

 

History

History
54 lines (37 loc) · 2.52 KB

DEVELOPMENT.md

File metadata and controls

54 lines (37 loc) · 2.52 KB

Development

Development happens in branch development. The main branch always tracks the latest release. Hence, create PRs against development. Use dedicated release/x.y.z branches to prepare releases and create release PRs against main, which will then be merged back into development.

Publishing

Create a GPG key with gpg --gen-key, and export it with gpg --keyring secring.gpg --export-secret-keys > ~/.gnupg/secring.gpg. Be sure to publish it with gpg --keyserver keyserver.ubuntu.com --send-keys <your-key-id>. See also the information in the Gradle docs.

Create a user token for your Nexus account on https://s01.oss.sonatype.org/ (in your profile) to use as sonatypeUsername and sonatypePassword.

Configure your ~/.gradle/gradle.properties:

signing.keyId=<last-8-chars>
signing.password=<private-key-password>
signing.secretKeyRingFile=<path-of-your-secring>
sonatypeUsername=<user-token-name>
sonatypePassword=<user-token-password>

To run the pipeline from GitHub, export your GPG key with gpg --export-secret-keys --armor <keyid> | tee <keyid>.asc and set the following environment variables:

ORG_GRADLE_PROJECT_signingKeyId=<last-8-chars>
ORG_GRADLE_PROJECT_signingKey=<ascii-armored-key>
ORG_GRADLE_PROJECT_signingPassword=<private-key-password>
ORG_GRADLE_PROJECT_sonatypeUsername=<user-token-name>
ORG_GRADLE_PROJECT_sonatypePassword=<user-token-password>

Actually, these environment variables are read from the repository secrets configured on Github.

Publish with:

./gradlew clean publishToSonatype

To also release the artifacts to Maven Central run:

./gradlew clean publishToSonatype closeAndReleaseSonatypeStagingRepository

To publish locally for testing, one can skip the signing tasks:

./gradlew clean publishToMavenLocal -x signJvmPublication -x signKotlinMultiplatformPublication -x signIosArm64Publication -x signIosSimulatorArm64Publication -x signIosX64Publication

Creating a new release

Create a release branch and do the usual commits, i.e. setting the version number and so on. Push it to Github. Run the workflow "Build iOS Framework", and attach the artefacts to the release info page on GitHub. Use the link from there to update the Swift Package, modifying Package.swift and entering the URLs. The checksum is the output of sha256sum *framework.zip.