Bug reports and pull requests are welcome on the GitHub issue tracker.
The SDK lives in lib/. Use the Gradle wrapper:
./gradlew build
./gradlew testbuild runs the test task, so the credentials note below applies to it too.
The suite has 139 unit tests plus four end-to-end classes under com.evervault.EndToEndTests
that call the Evervault API. Without credentials, those four fail at initialization instead of
being skipped, so a clean checkout reports a red build:
EncryptTest > initializationError FAILED
143 tests completed, 4 failed
Either supply credentials:
TEST_EV_APP_ID=app_xxx TEST_EV_API_KEY=ev:key:... ./gradlew testor run the unit tests alone:
./gradlew test --tests 'com.evervault.When*'Reproducing a specific CI Java version needs that JDK installed locally. Toolchain auto-provisioning is not configured, so the build fails with "No matching toolchains" if it is missing:
./gradlew test -PjavaToolchainVersion=8All configurations are locked. Adding, removing, or upgrading a dependency requires regenerating the lockfiles, or resolution fails:
./gradlew dependencies --write-locksCommit the resulting lib/gradle.lockfile and buildscript-gradle.lockfile.
We use changesets to manage versions.
A PR that should land in a release needs a changeset. Run pnpm changeset, pick the bump
level, and describe the change for the changelog. Do not pick major for a breaking change
without team approval.
Releasing is two steps, both on main:
- Merging a PR that contains changesets prompts the bot to open a "New Release" PR that
bumps the version in
package.jsonandlib/build.gradle. - Merging that PR tags the commit, creates the GitHub release, and stages the artifact to
Sonatype. Publishing to Maven Central then waits on manual approval of the
maven-centraldeployment environment. Until someone approves it, the release is staged but not public.
After approval the artifact appears at com.evervault:lib:<version> on Maven Central.