ci: add workflow to build and publish React Native Playground APK on release

[ffmcgee725]

Explanation

Adds automated CI infrastructure to build the React Native Playground Android APK and attach it to GitHub Releases, eliminating the manual build-and-transfer process that blocks running multichain RN connect E2E tests in metamask-mobile.

What

• New workflow (.github/workflows/build-rn-playground-apk.yml):

  • workflow_call (reusable from the release pipeline) + workflow_dispatch (manual/ad-hoc builds from any branch)
  • Full self-contained build: checkout → Node/Yarn/JDK setup → yarn build → Infura .env from secret → expo prebuild → gradlew assembleRelease
  • Uploads APK as a workflow artifact (90-day retention)
  • On release: attaches versioned rn-playground-<version>.apk to the GitHub Release via gh release upload
  • Gradle and Yarn caching for faster subsequent builds

• Release pipeline integration (publish-release.yml, main.yml):

  • New build-rn-playground-apk job runs after get-release-version (parallel with the existing gh-pages deployments)
  • Forwards INFURA_API_KEY secret through the workflow call chain

Why

The metamask-mobile Appwright E2E tests (multichain RN connect specs) require a prebuilt playground APK. Until now, generating it required manually cloning connect-monorepo, building locally, and transferring the APK — a process that doesn't scale for CI or new contributors. With this change, every release automatically produces a fetchable APK artifact.

Setup required

Add the INFURA_API_KEY secret to the connect-monorepo repository settings. The APK is signed with Expo's default debug keystore, which is sufficient for a test dApp.

Files changed

File	Change
.github/workflows/build-rn-playground-apk.yml	New reusable + dispatchable workflow
.github/workflows/publish-release.yml	New build-rn-playground-apk job, INFURA_API_KEY secret passthrough
.github/workflows/main.yml	Forward INFURA_API_KEY to publish-release.yml
playground/react-native-playground/README.md	CI build docs, secrets table, BrowserStack investigation

References

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed, highlighting breaking changes as necessary
• I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

[jiexi]

would this trigger on release of any package? Do we need to make this step run only if the react native playground is specifically being released?

[jiexi]

perhaps we need to target a new tag entirely, not the root level package.json version?

[adonesky1]

This is a good point. I think I had pointed Joao down this path of targeting any release, but I suppose it wouldn't make sense to run this unless the react-native-playground itself is being released

[adonesky1]

I think as @jiexi suggests we need a new tag format specifically for the rn playground package to do the proper gating comparison

[ffmcgee725]

Yes, it would run on every monorepo release regardless of which package changed. Since the playground depends on workspace packages (@metamask/connect-multichain, @metamask/connect-evm, etc.), rebuilding the APK on any release is actually desirable -- the playground bundles those packages at build time, so a new @metamask/connect-multichain release means the APK should be rebuilt to include it. The APK filename will still reflect the playground's own version, which only bumps when the playground itself changes (enforced by validate-release-playground-bumps.yml).

[jiexi]

I think that on the mobile side when we specify the github release url (identified by tag) to download the built RN playground APK from, that APK should never change. If the APK changes, it should be only if the github release url (i.e. tag) changes too.

If we allow clobbering the existing apk in a tag, this violates the assumptions of versioning (since there is a version in the github release url)

[ffmcgee725]

b4ea0d6

[adonesky1]

I don’t think b4ea0d6 fully closes the loop on Jiexi’s concern yet. The new gate is checking whether the RN playground tag already exists at all, not whether the playground was actually released in this specific run, so it could still fire on unrelated releases. On top of that, the APK is still being uploaded to the generic RELEASE_TAG, and with --clobber we can still overwrite an asset behind an existing release URL, which is the versioning issue Jiexi called out.

I think the safer path is:

1. only run the APK job when the RN playground itself is part of the current release
2. upload the APK to the RN-playground-specific tag (for example @metamask/[email protected]), not the generic release tag
3. avoid --clobber once that tag-to-APK mapping is versioned and stable

That way the mobile side can rely on a release URL never changing underneath it.

[ffmcgee725]

addressed concern here
c74d881

[adonesky1]

This looks right to me now! Will let @jiexi confirm though!

[adonesky1]

LGTM