appr builds and deploys pull requests in your create-react-native-app (and other Expo-based) projects, and replies with a link you can open directly on your device or emulator.
As of Expo SDK 26, the Expo iOS client is no longer able to open QR codes due to Apple App Store limitations. We are investigating on how to adapt appr to work with newer version of Expo iOS. In the meantime, appr only works for Android testing workflows and Expo SDK versions 25 and older on iOS.
noun
- appr - Pull Request Review Apps for React Native
- appr - Portmanteaux of app and PR.
- appr - Throwback to Web 2.0, when everything was bettr
Mature technical organizations peer-review their code. Reviewing code on GitHub is simple enough: for most well-crafted pull requests, you can review the code diff in your browser, and either approve the changes, or request further improvements.
Testing another developer's changes isn't quite as easy. Typically, you will have to stash any work in progress in your own workspace, pull down the remote branch, install dependencies, compile and start the application before you can verify that the changes work as intended.
Since it was launched, I've loved Heroku's GitHub-integrated Review Apps. As part of your branch build, Heroku will spin up a new review instance of your application, which you can then access with a direct link from your GitHub pull request. Netlify offers the same functionality for deploying static websites.
Unfortunately, a one-click workflow like this doesn't exist for mobile development. To add insult to injury, the ramp-up time to test mobile app changes on your local device can be much longer than for web applications.
Enter appr. Built on Expo and inspired by Expo Sketch, appr aims to make peer-reviewing React Native app code as easy as static websites. appr creates a new Expo Release Channel for every PR or branch you enable it on and automatically pushes your code to the release channel on every change.
Add appr
and exp
to your project.
yarn add --dev appr exp
Or, using npm:
npm install --dev appr exp
exp
, the Expo CLI, is a required peer dependency. In versions 1.x
of appr it was installed by default, so if your'e upgrading to appr@2.x
, please install exp
manually.
Add the appr
task to the scripts
section of your package.json:
scripts: {
+ "appr": "appr",
}
Next, configure one of the currently supported CI environments:
Contributions for other CI platforms welcome.
There are a few limitations you should be aware of. appr is currently not able to deploy:
- React Native apps started with something other than create-react-native-app or Expo.
- Ejected React Native apps containing custom native module dependencies.
- Pull Requests from forked repositories. This is due to Travis and Circle security policies (wisely) not exposing secure environment variables to forked builds. (Circle CI allows you to disable this setting, but it is not recommended!)
Contributions and ideas for solutions welcome.
Travis CI is free for open source projects, and offers paid plans for private repositories. To get started, create an account on Travis using your GitHub login.
Add the following to your .travis.yml
:
language: node_js
node_js:
- "node"
cache: yarn
script:
- 'if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then yarn appr; fi'
This will configure your Travis build to use the latest Node.js and Yarn, and ensure that the appr build only runs on Pull Request builds.
You may also want to automatically push some target branches, e.g. your develop
or master
branches to a release channel to test your integrated code. In that case, you can whitelist the branches to release in your .travis.yml
:
script:
- 'if [ "$TRAVIS_PULL_REQUEST" != "false" ] || [ "$TRAVIS_BRANCH" == "master" ]; then yarn appr; fi'
It's advisable to run your unit tests before deploying review apps. You can do this by adding other steps in the script
section, and always leaving the appr step last:
script:
+ - yarn ci-test-command
- 'if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then yarn appr; fi'
Note that the default test
command in create-react-native-app
runs Jest in --watch
mode, which will hang forever. You can either change the test
script in your package.json, or, or override the test command as above.
The final step is to enable Travis CI on your repository. Log into your Travis account, and turn on the build for your project in your Profile.
After enabled, you'll be taken to your project build page. Before triggering the first build, you'll need to add a few secure environment variables to your build under More options > Settings
:
EXP_USERNAME
- Exponent username, under which to publish the review apps. Use your main account, or create a new one for review apps. All review apps will be unlisted, so only you can see them in your app listings.EXP_PASSWORD
- Exponent password for the publish user.GITHUB_USERNAME
- A user account you want to use for posting the review app links. Use your own, or create a new "bot" account and grant them access to your repo.GITHUB_TOKEN
- A Personal API Token of the user with access to the repository. If the repository is private, the token needs to be granted the fullrepo
scope. For public repositories, thepublic_repo
scope is enough.
You should now be able to create a new branch, make changes, and open a pull request. If the stars are aligned, the Travis build should publish the app to Expo!
Circle CI offers one free build container for public and private repositories. To get started, create an account on Circle CI using your GitHub login.
Add the following to your circle.yml
:
dependencies:
override:
- yarn
machine:
node:
version: 6.9
deployment:
appr:
branch: /.*/
commands:
- 'if [ "$CI_PULL_REQUEST" != "" ]; then yarn appr; fi'
This will configure your Circle build to use the latest Node.js and Yarn (optional), and ensure that the appr build only runs on Pull Request builds.
You may also want to automatically push some target branches, e.g. your develop
or master
branches to a release channel to test your integrated code. In that case, you can whitelist the branches to release in your circle.yml
:
deployment:
appr:
branch: /.*/
commands:
- 'if [ "$CI_PULL_REQUEST" != "" ] || [ "$CIRCLE_BRANCH" == "master" ]; then yarn appr; fi'
Circle CI will automatically run your tests before the deployment. Note that the default test
command in create-react-native-app
runs Jest in --watch
mode, which will hang forever. You can either change the
test
script in your package.json, or, or override the test command in circle.yml:
test:
override:
- yarn ci-test-command
The final step is to enable Circl CI on your repository. Log into your Circle CI account, and turn on the build for your project.
After enabled, you'll be taken to your project build page. Before triggering the first build, you'll need to add a few secure environment variables to your build under [Gear icon] > Settings > Environment variables
:
EXP_USERNAME
- Exponent username, under which to publish the review apps. Use your main account, or create a new one for review apps. All review apps will be unlisted, so only you can see them in your app listings.EXP_PASSWORD
- Exponent password for the publish user.GITHUB_USERNAME
- A user account you want to use for posting the review app links. Use your own, or create a new "bot" account and grant them access to your repo.GITHUB_TOKEN
- A Personal API Token of the user with access to the repository. If the repository is private, the token needs to be granted the fullrepo
scope. For public repositories, thepublic_repo
scope is enough.
Optionally, you can enable Advanced settings > Only build pull requests
to avoid running build on branches that do not have open pull requests.
You should now be able to create a new branch, make changes, and open a pull request. If the stars are aligned, the Circle CI build should publish the app to Expo!
If your preferred CI is not explicitly supported by appr, but supports building GitHub pull requests, you can use it by defining environment variables as shown in the default config file.
Improvements and additions welcome. For large changes, please submit a discussion issue before jumping to coding; we'd hate you to waste the effort.
In lieu of a formal style guide, follow the included eslint rules, and use Prettier to format your code.
Archived: This project is no longer maintained by Formidable. We are no longer responding to issues or pull requests unless they relate to security concerns. We encourage interested developers to fork this project and make it their own!