chore: automate example app publishing to app stores - #5118
Draft
KisaneNeko wants to merge 2 commits into
Draft
KisaneNeko wants to merge 2 commits into
KisaneNeko wants to merge 2 commits into
Conversation
KisaneNeko
marked this pull request as draft
September 14, 2026 06:46
KisaneNeko
force-pushed
the
feat/automate-example-app-release
branch
from
September 14, 2026 19:36
8da1cee to
d1f8f7a
Compare
KisaneNeko
force-pushed
the
feat/automate-example-app-release
branch
from
September 22, 2026 10:26
d1f8f7a to
4bd1cee
Compare
|
Found potential problems with the pull request:
|
KisaneNeko
marked this pull request as ready for review
September 22, 2026 11:24
The example app in the stores drifts away from the library: it was released eighteen times in nine years against eighty-three library releases, all by hand, and the last one was twenty months ago. Ship it from the release that prompts it instead. What it ships depends on whether native code changed. `runtimeVersion` uses the fingerprint policy, so the workflow can compare the project against the builds already out there: unchanged means the new JavaScript runs on what people already have, and goes out as an update; changed means a build and a trip through the stores. Only a build carries a version to a store, so only a build bumps one, and that bump comes back as a pull request. This replaces the updates workflow, which published updates when a labelled pull request merged. It never ran once: it triggers on push, where the pull_request it tests does not exist, so all sixty-nine runs skipped. Tying both outcomes to the release removes the label nobody remembered to add. Prereleases and stable releases build against separate channels so an update published for an alpha cannot reach the stable app. Where a build lands is decided by the tag rather than by the release's prerelease flag, because .release-it.json pins every release to `preRelease: true` for the 6.0 alpha cycle, and reading that flag would route a stable 6.0.0 to the internal track. Publishing runs after a release already exists, so it cannot fail, revoke or roll back one. A run that does not succeed says so on its own run page, where the mail GitHub already sends the publisher leads, and says the release is unaffected. Store credentials live in EAS rather than here, so EXPO_TOKEN is the only secret this needs. Setup and the known limitations are in CONTRIBUTING.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
KisaneNeko
force-pushed
the
feat/automate-example-app-release
branch
from
September 23, 2026 05:58
4bd1cee to
fb463b2
Compare
Whether EXPO_TOKEN still works could otherwise only be found out by a real run, which builds and submits. A dry run authenticates, works out whether the release would build or update, reports that, and stops. Also check authentication in its own step, so a missing or expired token fails in seconds with a message that says so rather than several minutes later inside a build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
KisaneNeko
marked this pull request as draft
September 24, 2026 10:09
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The example app in the stores is 20 months out of date. It's only ever been updated by hand (18 times in nine years, against 83 library releases), so it drifts. This ships it with each library release instead.
Related issue
Resolves #4993
Screenshots / Videos
No UI changes.
Test plan
Needs
EXPO_TOKENand the store credentials in EAS first, setup steps are in CONTRIBUTING.md.On the next release: if no native code changed it should publish an OTA update and stop there. If it did, it should build, land on the Play internal track and TestFlight, and open a version bump PR. Stable releases go to Play production instead.
This also replaces
updates.yml, which did the OTA half on labelled PR merges. It never ran once (wrong trigger, so the label check never matched), and both halves belong on the same event.To check the failure path, cancel a run from the Actions tab and confirm the run page says the library release is unaffected.