Caching React Native Builds on S3 and R2 With Rock

One of the reasons we’ve decided to build Rock was the ability reuse native iOS and Android build artifacts by completely skipping builds that don’t need to happen. In our experience up to 95% of the commits for large-scale React Native apps only affect the JavaScript side. And yet, most teams will try to build the entire native app from scratch for every commit.

If that’s you, you’re spending up to 20x more compute on native builds than necessary. That’s a lot of wasted time (and money)!

Unless you use Rock In our framework, we’ve implemented a fingerprinting mechanism, based on @expo/fingerprintlibrary, that allows us to calculate a unique hashes that represent iOS and Android project. When you pair that with our GitHub Action, which will handle building, uploading and downloading your native builds from GitHub Artifacts.

The remote cache experience

With all that you can achieve a pretty great DX. Assuming your builds are happening in GitHub cloud, you have installed npm deps, and have the GitHub Personal Access Token set up, but haven’t build the project yet:

1. Start the dev server with rock start
2. Run the rock run:ios (or rock run:android) command in your Terminal, which will calculate the native hash for your project
3. The command will try to download the binary from GitHub Artifacts
   1. If it succeeds, the matching native artifact (APK, APP, or IPA) will be downloaded and installed to your selected device
   2. If it doesn’t find the artifact on remote cache, it will proceed with building locally, as you’re probably used to.

If all goes well, you’ll be up and running with your app from seconds. And if you have your GitHub Action set up to work on branches as well, you’ll be able to quickly jump into your colleague’s work in seconds too, even if it involves native changes.

Store builds on S3, R2 or anywhere

Storing the artifacts on GitHub was a major limitation for us. That’s why I’m particularly excited about the new feature that we shipped in latest Rock version: support for AWS S3 and Cloudflare R2 storage providers.

All you need to do is to add @rock-js/provider-s3 to your configuration and populate it with necessary data describing your bucket (its name and region), and also the access keys necessary to interact with AWS S3 API:

import { providerS3 } from '@rock-js/provider-s3';

export default {
  // ...
  remoteCacheProvider: providerS3({
    bucket: 'your-bucket',
    region: 'your-region',
    accessKeyId: process.env.S3_ACCESS_KEY_ID,
    secretAccessKey: process.env.S3_SECRET_ACCESS_KEY,
  }),
};

‍
And if instead of S3 you want to use R2, all you need to do is add the endpoint config option, which points to your bucket on Cloudflare:

remoteCacheProvider: providerS3({
  endpoint: 'https://${ACCOUNT_ID}.r2.cloudflarestorage.com',
  // ... rest of the config
}),

Ok, that’s almost all you need to do. Adding this feature required as to create better internal abstractions for our GitHub Actions, for which we’ve created a new remote-cache command to handle all providers in a universal way. As a result, we’ve released a v2 of our callstackincubator/ios action, currently tagged as v2-rc, that handles building, downloading, uploading, and deleting iOS artifacts from S3 or R2 for you.

If you’re already using Rock, you can update your workflow file like this:

-uses: callstackincubator/ios@v1
+uses: callstackincubator/ios@v2-rc

And add pass necessary environment variables (unless you have other means of populating these) to that action:

env:
    S3_ACCESS_KEY_ID: ${{ secrets.S3_ACCESS_KEY_ID }}
    S3_SECRET_ACCESS_KEY: ${{ secrets.S3_SECRET_ACCESS_KEY }}

And if you’re not using Rock yet, follow the migration from Community CLI docs or start a new project.

Going forward, the v2 of our GitHub Actions for both iOS and Android will support any remote cache provider compatible with Rock, be it GitHub, S3, R2, or a custom one which you can build yourself.

Give it a try

We’re super excited about the new capabilities of Rock and that you’ll now be able to use it in a more broad range of scenarios. Please give it a go, test it with your buckets and leave us feedback in a form of GitHub issues and PRs. We’re off the GitHub Artifacts leash for good and on for some new features to come. Stay tuned!