Release 1.50.0

.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:
@@ -79,7 +79,7 @@ jobs:
           name: Install newer node using nvm
           command: |
             cd gutenberg
-            nvm install --latest-npm
+            nvm install
       - when:
           condition: <<parameters.check-correctness>>
           steps:
@@ -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

Gutenberg.podspec

@@ -12,7 +12,7 @@ Pod::Spec.new do |s|
   s.homepage     = 'https://github.com/wordpress-mobile/gutenberg-mobile'
   s.license      = gutenbergMobilePackage['license']
   s.authors          = 'Automattic'
-  s.platform     = :ios, '11.0'
+  s.platform     = :ios, '13.0'
   s.source       = { :git => 'https://github.com/wordpress-mobile/gutenberg-mobile.git', :submodules => true }
   s.source_files = 'gutenberg/packages/react-native-bridge/ios/**/*.{h,m,swift}'
   s.requires_arc = true

README.md

@@ -40,7 +40,7 @@ Before running the demo app, you need to download and install the project depend
 
 ```
 cd gutenberg
-nvm install --latest-npm
+nvm install
 cd ..
 npm install
 ```
@@ -97,7 +97,7 @@ Although you're not required to use Visual Studio Code for developing gutenberg-
 
 When you first open the project in Visual Studio, you will be prompted to install some recommended extensions. This will help with some things like type checking and debugging.
 
-![Prompt to install recommended extensions](images/recommended-extensions.png)
+![Prompt to install recommended extensions](https://github.com/WordPress/gutenberg/blob/7532a485b400f86638145b71f94f6f717e5add25/packages/react-native-editor/images/recommended-extensions.png)
 
 One of the extensions we are using is the [React Native Tools](https://marketplace.visualstudio.com/items?itemName=vsmobile.vscode-react-native). This allows you to run the packager from VSCode or launch the application on iOS or Android. It also adds some debug configurations so you can set breakpoints and debug the application directly from VSCode. Take a look at the [extension documentation](https://marketplace.visualstudio.com/items?itemName=vsmobile.vscode-react-native) for more details.
 
@@ -121,7 +121,7 @@ Then, open `chrome://inspect` in Chrome to attach the debugger (look into the "R
 
 ## Writing and Running Unit Tests
 
-This project is set up to use [jest](https://facebook.github.io/jest/) for tests. You can configure whatever testing strategy you like, but jest works out of the box. Create test files in directories called `__tests__` or with the `.test.js` extension to have the files loaded by jest. See an example test [here](https://github.com/wordpress-mobile/gutenberg-mobile/blob/develop/src/index.test.js). The [jest documentation](https://facebook.github.io/jest/docs/en/getting-started.html) is also a wonderful resource, as is the [React Native testing tutorial](https://facebook.github.io/jest/docs/en/tutorial-react-native.html).
+This project is set up to use [jest](https://facebook.github.io/jest/) for tests. You can configure whatever testing strategy you like, but jest works out of the box. Create test files in directories called `__tests__` or with the `.test.js` extension to have the files loaded by jest. See an example test [here](https://github.com/WordPress/gutenberg/blob/HEAD/packages/react-native-editor/src/test/api-fetch-setup.test.js). The [jest documentation](https://facebook.github.io/jest/docs/en/getting-started.html) is also a wonderful resource, as is the [React Native testing tutorial](https://facebook.github.io/jest/docs/en/tutorial-react-native.html).
 
 ## UI Tests
 
@@ -145,11 +145,11 @@ To run a single test instead of the entire suite, use `npm run device-tests:loca
 
 Note: You might experience problems that seem to be related to the tests starting the Appium server, e.g. errors that say `Connection Refused`, `Connection Reset` or `The requested environment is not available`. For now, you can manually start the Appium server via [appium desktop](https://github.com/appium/appium-desktop) or the CLI, then change the port number in the tests while (optionally) commenting out related code in the `beforeAll` and `afterAll` block. 
 
-For a more detailed outline of the UI tests and how to get started writing one, please visit the [UI Test documentation](https://github.com/wordpress-mobile/gutenberg-mobile/blob/develop/__device-tests__/README.md) and our [contributing guide](https://github.com/wordpress-mobile/gutenberg-mobile/blob/develop/__device-tests__/CONTRIBUTING.md).
+For a more detailed outline of the UI tests and how to get started writing one, please visit the [UI Test documentation](https://github.com/WordPress/gutenberg/blob/HEAD/packages/react-native-editor/__device-tests__/README.md) and our [contributing guide](https://github.com/WordPress/gutenberg/blob/HEAD/packages/react-native-editor/__device-tests__/CONTRIBUTING.md).
 
 ## Static analysis and code style
 
-The project includes a linter (`eslint`) to perform codestyle and static analysis of the code. The configuration used is the same as [the one in the Gutenberg project](https://github.com/WordPress/gutenberg/blob/master/eslint/config.js). To perform the check, run:
+The project includes a linter (`eslint`) to perform codestyle and static analysis of the code. The configuration used is the same as [the one in the Gutenberg project](https://github.com/WordPress/gutenberg/blob/HEAD/packages/eslint-plugin/README.md). To perform the check, run:
 
 ```
 npm run lint

RELEASE-NOTES.txt

@@ -1,6 +1,11 @@
 Unreleased
 ------
 
+1.50.0
+------
+* [***] a11y: Screenreader improvements for the UnitControl component [https://github.com/WordPress/gutenberg/pull/29741]
+* [*] Block split/merge fix for a (never shipped) regression (Android only) [https://github.com/WordPress/gutenberg/pull/29683]
+
 1.49.0
 ------
 * [*] Remove the cancel button from settings options (Android only) [https://github.com/WordPress/gutenberg/pull/29599]

RNTAztecView.podspec

@@ -13,7 +13,7 @@ Pod::Spec.new do |s|
   s.source_files     = 'gutenberg/packages/react-native-aztec/ios/RNTAztecView/*.{h,m,swift}'
   s.public_header_files = 'gutenberg/packages/react-native-aztec/ios/RNTAztecView/*.h'
   s.requires_arc     = true
-  s.platforms        = { :ios => "11.0" }
+  s.platforms        = { :ios => "13.0" }
   s.swift_version    = '5.0'
   s.xcconfig         = {'OTHER_LDFLAGS' => '-lxml2',
                         'HEADER_SEARCH_PATHS' => '/usr/include/libxml2'}