Publish React Native Bridge to Bintray from CI

.circleci/config.yml

@@ -49,11 +49,11 @@ parameters:
   android-docker-image:
     type: string
     # Hash points to previous version with node 12. When everything works with node 14 it can be removed
-    default: "circleci/android:api-29-node@sha256:71d61d6c21b29948d57120f476a83cc322a280979bce355c5a0ad771293ca380" 
+    default: "circleci/android:api-29-node@sha256:71d61d6c21b29948d57120f476a83cc322a280979bce355c5a0ad771293ca380"
   linux-machine-image:
     type: string
     # Latest supported ubuntu image from https://circleci.com/docs/2.0/configuration-reference/#available-machine-images
-    default: "ubuntu-2004:202010-01" 
+    default: "ubuntu-2004:202010-01"
 
 jobs:
   checks:
@@ -253,6 +253,104 @@ jobs:
                 include_job_number_field: false
                 include_project_field: false
                 failure_message: ':red_circle: Scheduled tests failed on iOS device!'
+  android-build-and-publish-react-native-bridge:
+    # This job builds the JS bunle required by the Android version of the
+    # react-native-bridge package, builds the AAR for that package, and uploads
+    # it to Bintray.
+    #
+    # Running on a Ubuntu machine to have more memory compared to the Docker +
+    # Node or Docker + Android images that CircleCI offers (circleci/node)
+    #
+    # Also running all in one job so that we can bail out early under cetrain
+    # conditions and save CI cycles.
+    #
+    # See: https://github.com/wordpress-mobile/gutenberg-mobile/pull/3038#issuecomment-765334675
+    machine:
+      image: << pipeline.parameters.linux-machine-image >>
+    steps:
+      - run:
+          name: Evaluate whether to run
+          command: |
+            # This is a partial duplication of the logic to compute the version
+            # to use for the AAR from below. It's useful to have it here
+            # because there are conditions under which we shouldn't run the job
+            # that can't be captured in a CircleCI filter.
+            #
+            # Exiting here saves a non-trivial amount of CI time because of how
+            # heavy the repo is to checkout (it takes at least 1 minute) and
+            # how time consuming running `npm ci` is.
+            if [[ -z ${CIRCLE_TAG+x} ]]; then
+              if [[ -n "$CIRCLE_PULL_REQUEST" ]]; then
+                echo "Build initiated from a branch with a pull request: proceeding..."
+              elif [[ $CIRCLE_BRANCH == "develop" ]]; then
+                echo "Build initiated on $CIRCLE_BRANCH: proceeding..."
+              else
+                # We end up here on the first push of a new branch, when there
+                # isn't a PR open for it yet.
+                echo "Build initiated from a feature branch with no pull request: aborting."
+                circleci-agent step halt
+              fi
+            else
+              echo "Build initiated from a tag: proceeding..."
+            fi
+      - checkout
+      - checkout-submodules
+      - run:
+          # Setting up Android before fetching the Node dependencies because
+          # this step is faster, so if it fails we'll learn about it sooner and
+          # avoid wasting cycles.
+          name: Setup Android Tooling
+          command: .circleci/setup-android-on-ubuntu.sh
+      - npm-install
+      - run:
+          name: Build JavaScript Bundle
+          command: npm run bundle:android
+          # The job can take a long time, so let's bump the no_output_timeout
+          # to more than the default 10m
+          no_output_timeout: 20m
+      - run:
+          name: Build React Native Bridge & Upload to Bintray
+          environment:
+            # This value is set in the setup script, but I'm not sure whether
+            # it's available after executing it
+            ANDROID_SDK_ROOT: /usr/lib/android-sdk
+          command: |
+            # We publish from PRs as well as the main branch and tags to help
+            # developers to iterate faster.
+            #
+            # The builds from a PR have a different version so that they can be
+            # deleted by
+            # https://github.com/Automattic/bintray-garbage-collector/
+            # once their PR is merged.
+            #
+            # If we're not on a PR but a merge commit on the develop branch the
+            # version will be the "develop-" followed by the commit SHA1.
+            #
+            # On a tag, the version should be the tag value.
+            #
+            # If we're on a different branch that has no open PR, we should
+            # not build and exit early instead.
+            if [[ -z "${CIRCLE_TAG+x}" ]]; then
+              if [[ -n "$CIRCLE_PULL_REQUEST" ]]; then
+                PR_NUMBER=$(basename $CIRCLE_PULL_REQUEST)
+                # CIRCLE_SHA1 should always be available.
+                VERSION="$PR_NUMBER-$CIRCLE_SHA1"
+              elif [[ $CIRCLE_BRANCH == "develop" ]]; then
+                VERSION="$CIRCLE_BRANCH-$CIRCLE_SHA1"
+              else
+                # This happens on the first push of a new branch, when there
+                # isn't a PR open for it yet.
+                echo "Running on a feature branch with no open PR."
+                echo "The checks previous to this step should not have let this happen."
+                exit 1
+              fi
+            else
+              VERSION=$CIRCLE_TAG
+            fi
+
+            cd gutenberg/packages/react-native-bridge/android
+
+            ./publish-aztec-and-bridge.sh $VERSION
 
 workflows:
   gutenberg-mobile:
@@ -301,6 +399,15 @@ workflows:
           filters:
             branches:
               only: /^dependabot/submodules/.*/
+      - android-build-and-publish-react-native-bridge:
+          name: Build Android RN Bridge & Publish to Bintray
+          filters:
+            branches:
+              # Don't run on trunk, otherwise, run on every other branch
+              ignore: trunk
+            tags:
+              # Run for every tag
+              only: /.*/
 
   ui-tests-full-scheduled:
     jobs:

.circleci/setup-android-on-ubuntu.sh

@@ -0,0 +1,68 @@
+#!/bin/bash
+
+set -e
+
+# Update the packages list, just in case
+sudo apt update
+
+# Android depends on Java. Luckily, the Ubuntu machine that CircleCI provides
+# already includes it. If that wouldn't the case, we'd need to install
+# openjdk-11-jdk.
+
+# Install the Android SDK
+sudo apt install android-sdk
+
+# The Android SDK gets installed in /usr/lib/. Some of the tools expect the SDK
+# location to be available via a known environment variable, so let's export
+# it.
+export ANDROID_SDK_ROOT=/usr/lib/android-sdk
+
+# Next, we need to install the command line tools to access the sdkmanager tool
+# to 1) install the platform and build-tools that the project needs and 2)
+# agree to the licenses so we can run the tools.
+#
+# For some reason, the SDK doesn't come with the command line tools. They are
+# not shipped via apt either. We need to download them manually.
+#
+# You can see what the latest version is at:
+# https://developer.android.com/studio#command-tools
+#
+# See also:
+# https://stackoverflow.com/questions/53994924/sdkmanager-command-not-found-after-installing-android-sdk
+cmd_line_tools_version=6858069
+cmd_line_tools_zip_name="commandlinetools-linux-${cmd_line_tools_version}_latest.zip"
+wget https://dl.google.com/android/repository/$cmd_line_tools_zip_name
+unzip $cmd_line_tools_zip_name
+
+# Move the command line tools in the location they expect to be in to work.
+#
+# Alternatively, we could keep them here but then we'd have to pass the
+# $ANDROID_SDK_ROOT location to each invocation of the sdkmanager command line
+# tool using the --sdk_root option. Doing so would also result in the extra
+# platform and build tool we'd install to end up in / rather than in the
+# correct subfolder of $ANDROID_SDK_ROOT.
+cmdline_tools_root=$ANDROID_SDK_ROOT/cmdline-tools
+sudo mkdir $cmdline_tools_root
+cmdline_tools_location=$cmdline_tools_root/latest
+sudo mv ./cmdline-tools $cmdline_tools_location
+
+# Store the path to sdkmanager for easier access in the rest of the script.
+#
+# This script is meant to run on a CI machine that gets torn down on every run.
+#
+# If this was a development machine instead, we would add the whole command line tools bin folder to the path by adding this to the RC file of the shell in use (e.g.: .bashrc or .zshrc):
+#
+# export PATH=$PATH:$cmdline_tools_location/bin/
+sdkmanager_bin=$cmdline_tools_location/bin/sdkmanager
+
+# We need a specific version of the Android platform and build tools.
+build_tools_version="29.0.2"
+platform_version="28"
+yes | sudo $sdkmanager_bin --install "build-tools;$build_tools_version"
+yes | sudo $sdkmanager_bin --install "platforms;android-$platform_version"
+# Apparently, we also need platform version 29?
+# See https://app.circleci.com/pipelines/github/wordpress-mobile/gutenberg-mobile/10739/workflows/a96e43eb-6d64-490e-87ab-ef1f1df2eb1d/jobs/56631
+yes | sudo $sdkmanager_bin --install "platforms;android-29"
+
+# Accept the licenses
+yes | sudo $sdkmanager_bin --licenses

WPAndroid Integration.md

@@ -0,0 +1,119 @@
+# WordPress Android Integration Guide
+
+### Summary
+
+WPAndroid by default integrates `react-native-bridge` as a binary dependency that's fetched from a remote maven repo.
+The CI in this repo will deploy a new version each time a commit is pushed to `develop` or an open PR, as well as each time a tag is created.
+This is the only required dependency.
+Whenever a new version is deployed, we can simply update `ext.gutenbergMobileVersion` in [build.gradle](https://github.com/wordpress-mobile/WordPress-Android/blob/develop/build.gradle).
+
+During development, we can use composite builds and dependency substitution to point WPAndroid to our local checkout of `gutenberg-mobile`.
+To do this, we need to copy the [local-builds.gradle-example file](https://github.com/wordpress-mobile/WordPress-Android/blob/develop/local-builds.gradle-example) in WPAndroid renaming it to `local-builds.gradle` and change the `localGutenbergMobilePath` value.
+Building the project as such will make WPAndroid build the source code for `react-native-bridge`, `react-native-aztec` and other sublibraries from the locally checked out folder.
+It'll also expect the metro server to be running to fetch the JS bundle.
+
+- [Work with local gutenberg-mobile checkout](#work-with-local-gutenberg-mobile-checkout)
+- [Deploy a new version of `react-native-bridge` from CI](#deploy-a-new-version-of-react-native-bridge-from-ci)
+- [Manually deploy a new version of `react-native-bridge`](#manually-deploy-a-new-version-of-react-native-bridge)
+- [Update WPAndroid's binary version](#update-wpandroids-binary-version)
+- [How to](#how-to)
+    - [How to test a gutenberg-mobile PR in WPAndroid](how-to-test-a-gutenberg-mobile-pr-in-wpandroid)
+    - [How to share WIP WPAndroid APK](how-to-share-wip-wpandroid-apk)
+    - [How to checkout gutenberg-mobile to deployed binary version](#how-to-checkout-gutenberg-mobile-to-deployed-binary-version)
+
+---
+
+### Work with local gutenberg-mobile checkout
+
+From your gutenberg-mobile checkout:
+
+- Make sure you run `npm install` or `npm ci`
+- Run metro server with `npm run start:reset`
+
+From your WordPress-Android checkout:
+
+- Copy [local-builds.gradle-example](https://github.com/wordpress-mobile/WordPress-Android/blob/develop/local-builds.gradle-example) renaming it to `local-builds.gradle`
+- Update `localGutenbergMobilePath`to your local `gutenberg-mobile`checkout
+- Run the project
+
+#### How it works:
+
+When [settings.gradle](https://github.com/wordpress-mobile/WordPress-Android/blob/develop/settings.gradle) finds `localGutenbergMobilePath` in `local-builds.gradle`, it'll substitute the below binary dependency with the local folder:
+
+```
+implementation "$rootProject.gradle.ext.gutenbergMobileBinaryPath:$rootProject.ext.gutenbergMobileVersion"
+```
+
+`react-native-bridge` is setup to include all the other projects, so no other action is necessary.
+
+---
+
+### Deploy a new version of `react-native-bridge` from CI
+
+There are a few different ways to do this:
+
+1. Open a new PR or push a new commit to an open PR which will be published as `<PR number>-<commit full SHA1>`
+2. Merge a PR to `develop` which will be published as `<develop>-<commit full SHA1>`
+3. Create a new tag which will be published as `<tag name>`
+
+#### How it works:
+
+CI will run the following commands:
+
+- `npm ci`
+- `npm run bundle:android`
+- `gutenberg/packages/react-native-bridge/android/publish-aztec-and-bridge.sh <version>`
+
+---
+
+### Manually deploy a new version of `react-native-bridge`
+
+_**IMPORTANT:** This should only be used for testing.
+We shouldn't commit a manually deployed version to WPAndroid's `develop` because the process bypasses the guarantees CI would otherwise give us._
+
+- Make sure you run `npm install` or `npm ci` first
+- Run `npm run bundle:android` so the JS bundle is created
+- Run `publish-aztec-and-bridge.sh` script in `react-native-bridge`, with the version name as its argument. i.e `./gutenberg/packages/react-native-bridge/android/publish-aztec-and-bridge.sh locally-built-by-<your_name>-<commit full SHA1>`
+
+#### How it works:
+
+Besides checking a few things, `publish-aztec-and-bridge.sh` script will clean the project, copy the bundled JS file into its assets, publish `react-native-aztec` and use that version to build and publish `react-native-bridge`.
+
+---
+
+### Update WPAndroid's binary version
+
+- Find [the version deployed from CI](#deploy-a-new-version-of-react-native-bridge-from-ci) or [the version you've manually deployed](#manually-deploy-a-new-version-of-react-native-bridge)
+- Update `ext.gutenbergMobileVersion` property in [build.gradle](https://github.com/wordpress-mobile/WordPress-Android/blob/develop/build.gradle) to the new version
+
+In order to test this, make sure `localGutenbergMobilePath` in your `local-builds.gradle` file is commented out as otherwise the binary version will be ignored.
+
+---
+
+## How to
+
+### How to test a gutenberg-mobile PR in WPAndroid
+
+Assuming that there is no open WPAndroid PR yet:
+
+1. Setup WPAndroid to [work with local gutenberg-mobile checkout](#work-with-local-gutenberg-mobile-checkout)
+2. Switch `gutenberg-mobile` to the branch you're testing
+3. Run the app
+
+---
+
+### How to share a WIP WPAndroid APK
+
+1. Either (a) open a `gutenberg-mobile` PR which will [publish a new version](#deploy-a-new-version-of-react-native-bridge-from-ci) or (b) [manually publish a new version](#manually-deploy-a-new-version-of-react-native-bridge)
+2. Open a WPAndroid PR [updating the binary version](#update-wpandroids-binary-version)
+3. Peril will publish a comment to the WPAndroid PR with a link to the APK
+
+Alternatively, once the `react-native-bridge` version is published, we can locally create the APK.
+**Note that there is no way to use composite build to create a WPAndroid APK that can be shared. This is because composite build only works with the local metro server.**
+
+---
+
+### How to checkout gutenberg-mobile to deployed binary version
+
+Whenever the CI publishes `react-native-bridge`, it will either include the full commit hash or the tag in its name.
+So, we can checkout simply checkout the commit hash or the tag.