Deploying to internal hello maven repo

Prerequisites

You will need a AWS-S3 access key/secret key pair that gives you read/write access to the s3://hello-maven/snapshot and s3://hello-maven/release buckets. You can acquire this key pair from Tim Bart.

Once you've acquired this key pair, you will need to add it to your global gradle properties file. On OS X, this properties file is located at ~/.gradle/gradle.properties. Add lines like the following to your properties file:

helloAwsAccessKeyID=LetMeIntoTheBuckets
helloAwsSecretKey=1mV3ry$3cr3t

Preparation

After you've made your changes, be sure to add any applicable unit tests, and verify that the existing tests in the project still pass. Once you've done this, you can update the VERSION_NAME field at the top of ble/build.gradle. The version name should take the form of <year>.<month>.<day>.<build-number>. An example version name is 2016.1.13.1.

If you need to deploy tentative changes that will not be pushed to the public, you may publish to the snapshot repository by appending -SNAPSHOT to your version name, e.g. 2016.1.13.1-SNAPSHOT. Only deploy snapshots if your dependent projects need to pass remote continuous integration, otherwise you should deploy to your local maven repository instead.

After you've done these steps, create a pull request to merge your changes into master. If your changes are limited to updating dependency versions in the ble/build.gradle file, once continuous integration passes on your branch, you can merge without a 👍.

Deployment

Once your changes branch has been merged into master, pull the latest changes onto your computer. After you have the changes, run the following gradle command inside of your local android-commonsense directory:

./gradlew clean build publish

If the build succeeds, this will publish the aar, javadoc and sources jars to the internal maven repository.

Once you've successfully pushed, you should tag your new version and push it to GitHub, like so:

git tag 2016.1.13.1
git push origin --tags

Addendum: Testing Changes Locally

Before you create a pull request to deploy your changes to one of the publicly available libraries, you will want to test your changes locally with our internal projects (e.g. suripu-android). To do this, you can deploy the libraries to your local maven repository like so:

# in project directory
./gradlew clean build publishMavenJavaPublicationToMavenLocal

Then, in your local copy of the suripu-android project, add a reference to maven local in your root project build.gradle file, like so:

// in `suripu-android/build.gradle`
// ...
allprojects {
    repositories {
        jcenter()
        mavenLocal()
        // ...
    }
}

Important: the maven local repository must come after any remote repositories.

You can then sync your project to pull in your local changes. Never push code to the remote repository with a maven local reference, it reduces the reproducibility of builds.