Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55429
Completes this stack of diffs focused around the organisation and efficiency of the `test-all` GitHub Actions workflow.
**Changed**
All root jobs (excluding `lint`), when running against a PR, now depend on the initial `check_code_changes` job. This matches any non-Markdown, non docs change — meaning trivial PRs such as changelog updates should now avoid unnecessarily running the expensive parts of this workflow.
IMPORTANT: This is a significant change at the root of the workflow that contributes to our prebuilts/release infra — please review carefully.
**The new `any_code_change` filter**
Extremely defensive:
- Matches `'!**/__docs__/**', '!**/*.md'` only.
- Also **always** sets `any_code_change` to true if on `main`, a release branch, or on a workflow dispatch (`github.event_name != 'pull_request'`).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D92417918
fbshipit-source-id: ca5bc41a3c11569b8f69062ab66eeeab89d30089
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55428
With a lighter weight `lint` job, make this blocking for `test_js` runs. The combined `lint` + `test_js` execution time in series remains far less than the native build+test jobs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D92417805
fbshipit-source-id: 05832257518c8141ca0955f18e740f752e675d4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55427
Following previous diffs, this now promotes the `lint` action to direct job steps.
**Motivation**
This has the advantage of making sub-steps in the GitHub UI visible, rather than running the 7 lint steps under a single banner.
I feel this is justified in the case of `lint`, although increasing the size of `.github/workflowsl/test-all.yml` slightly, because:
- Each step in this job is a distinct tool run with differing output, rather than one logical "action" — and this grouped output is therefore useful to the user.
- Lint failures are reasonably frequent for users, emphasising the above.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D92417807
fbshipit-source-id: ed24cfa2e581a528e80faec4128d280926f56613
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55425
See blame — this script lints for a `"PATENTS"` string inside any Git changes, which should not occur any more.
> D7119356 (8 years ago)
>
> [react-native][PR] Check PATENTS does not creep into files
>
> Summary:
> Some files have crept into the repo with the old license header. These are usually from PRs that were opened prior to the re-licensing of the project.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D92417808
fbshipit-source-id: 36e3507f835fe5df99644eb1a47cdc60fa68f88c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55421
Deletes the largely unused `analyze_code`/`code-analysis-bot` script, which was part of our earlier CircleCI infra.
**Motivation**
- **Security**: Removes another use of a `GITHUB_TOKEN` env var being loaded into a script in our CI (similar to S603729).
- **Cleanup**: This script attempted to read various lint job results (including google-java-format, which is no longer present), and post a GitHub PR comment for >5 issues. In a GitHub Actions world, we don't really need this functionality.
**Other changes**
- The `yarn shellcheck` run from this script was load bearing, and is moved directly into the `lint` action.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D92407627
fbshipit-source-id: ef5664a273ad4aac721dbb53de73f2b96b47d75b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55416
Adds a `build_debugger_shell` job as part of the `test-all` workflow, adding missing coverage to `scripts/debugger-shell/build-binary.js`. This was broken recently by https://github.com/facebook/react-native/pull/54857.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D92396626
fbshipit-source-id: dda9427a936c46ec74821c10a8578c8a299890e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55420
After https://github.com/facebook/react-native/pull/54857 (use of the "publishConfig" field), this check is no longer necessary, since `yarn build` will no longer make changes to any checked in files.
In the (expectedly) rare case that `yarn build --prepack` changes are committed (only intended for CI), Flow will also fail independently.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D92397786
fbshipit-source-id: 872cc91b62295cdb6d8c2799cffb8a4cadc4106e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55245
Changelog: [INTERNAL] [FIXED] - Fix diff-js-api-changes workflow to correctly compare PR head vs merge base
The `diff-js-api-changes` action was comparing main to main instead of comparing the PR head to the point of main it branched from.
The workflow now:
1. Checks out main in `danger-pr.yml` to get the trusted scripts
2. Fetches the PR head commit and computes the merge base (the point it branched from main)
3. Extracts the API snapshots from both refs using `git show` to read-only temp files
4. Runs main's diff script to compare the two snapshots
**Security notes:**
- `git fetch` only downloads git objects, it does not modify the working directory
- `git show <sha>:path` extracts a file as read-only data, not executable code
- All executed scripts come from main (trusted), PR content is only used as data
- The PR's `.d.ts` file is written to a temp directory and passed as input to main's diff script
Reviewed By: huntie
Differential Revision: D90978905
fbshipit-source-id: fc9b420a27c84f1812b436f41d3169fad4f91291
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55232
Changelog: [Internal]
As suggested by cipolleschi, this is a more stable solution given that the workflow has been consistently failing for the past couple of RCs.
Reviewed By: cipolleschi
Differential Revision: D90992194
fbshipit-source-id: 7586a4bf141a875b2d780d1a359e79fc42c9ffda
Summary:
Fixes a typo on the step name of `maestro-ios` gh action:
From `Set up JDK 11` -? `Set up JDK 17`
to match the actual version and be in sync with the rest of the other actions (e.g. maestro-android)
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - typo on maestro ios gh action for jdk step
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/55167
Test Plan: No testing required
Reviewed By: cipolleschi
Differential Revision: D90688156
Pulled By: cortinico
fbshipit-source-id: d2f4ff27bd6cee18c5931ff81df5f965ddf6d01b
Summary:
Now that we are using prebuilds by default in the release, we should also use prebuilds when running the E2E tests of the template app
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/55156
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D90673567
Pulled By: cipolleschi
fbshipit-source-id: d99c8f89f0c8737a7cb00eba654037997e661b95
Summary:
When setting up Xcode, we also download the SDKs that is needed.
There might be cases where we can save money and time and skip the download
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/55147
Test Plan: GHA
Reviewed By: javache
Differential Revision: D90594740
Pulled By: cipolleschi
fbshipit-source-id: 2923d891d626dfbb8446641d37b4b3f896c1daf2
Summary:
This change makes Hermes V1 the default engine for React Native for both platforms. This change needs to land before the branch cut of react native 0.84
bypass-github-export-checks
## Changelog:
[iOS][Changed] - Make Hermes V1 the default engine for iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/54989
Test Plan:
1. Run `bundle exec pod install` and verified that Hermes V1 is used when building from source
<img height="480" alt="Simulator Screenshot - iPhone 17 Pro - 2025-12-29 at 11 28 44" src="https://github.com/user-attachments/assets/0889f16c-f2ee-4a0e-9a4d-529dd82c8283" />
2. Run `prebuild-ios -s` and verified that the scripts downloads the Hermes V1 tarball
<img width="831" height="324" alt="Screenshot 2025-12-29 at 10 37 53" src="https://github.com/user-attachments/assets/9a60565e-1e13-4967-a4a4-dd079e6b040f" />
3. GHA and nightlies
Reviewed By: vzaidman, cortinico, huntie
Differential Revision: D89881943
Pulled By: cipolleschi
fbshipit-source-id: 958b6d31bd4230ba4a5c7fee2bffc19e03dcbc89
Summary:
This is a pick of 4cac35f7d0 inside `main`.
The commit is already on the `0.84-stable` branch.
The reasoning here is that `cat` + `jq` failed to run with:
```
Run echo "rn-version=$(cat packages/react-native/package.json | jq -r 'version')" >> $GITHUB_OUTPUT
echo "rn-version=$(cat packages/react-native/package.json | jq -r 'version')" >> $GITHUB_OUTPUT
shell: bash --noprofile --norc -e -o pipefail {0}
jq: error: version/0 is not defined at <top-level>, line 1:
version
jq: 1 compile error
```
I'm moving to a single `jq` invocation as it's more resilient.
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/55057
Test Plan: N/A
Reviewed By: fabriziocucci, alanleedev
Differential Revision: D90189240
Pulled By: cortinico
fbshipit-source-id: 9b1cd6ad6d37913f8a468892cedce5f808c8c33e
Summary:
This is a cherry-pick of dc90b0b7f3 on main from 0.83 and 0.84
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/55054
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D90174387
Pulled By: cortinico
fbshipit-source-id: 74b0ec3b853f2654ce140b9af27f13fe22c81f4a
Summary:
Fantom tests are a bit flaky, so we are rerunning them in case they fails.
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/55053
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D90174181
Pulled By: cipolleschi
fbshipit-source-id: 131d6fb68a9a53eaef5b36c0f0fe9adf989219b3
Summary:
In my prs, Im seeing the validate-dotslash-artifacts job fail with the error:
```
error react-native@1000.0.0: The engine "node" is incompatible with this module. Expected version ">= 22.11.0". Got "20.19.6"
error Found incompatible module.
```
This change should fix the job by setting up a compatible version of Node
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/55049
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D90168396
Pulled By: cipolleschi
fbshipit-source-id: 8d81f37a62ca13d5e868869b488eec4ea36d17c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55047
Changelog: [Internal]
Fixed typos found through comprehensive recursive scan of the react-native-github directory.
**Fixed typos:**
1. "accomodate" → "accommodate" in CHANGELOG-0.6x.md
2. "occured" → "occurred" in LaunchUtils.js
3. "compatability" → "compatibility" in 7 Renderer files
4. "recieved" → "received" in PointerEvent test files (6 instances)
5. "seperated" → "separated" in ImageExample.js
**Total: 16 typo instances fixed across 10 files**
All typos were found by scanning ~3000 text files (excluding dist/third-party/node_modules) using pattern matching for common misspellings.
Reviewed By: javache
Differential Revision: D89799362
fbshipit-source-id: 73e9123dc0bae3c1ce8e374f4752404ab7345347
Summary:
While running `yarn spellcheck` I have spotted that scripts located in `/vendor` directory are checked, which lead to a lot of warnings in the output.
This PR adds an exclusion for the `/vendor` path in the spellcheck script which leads to way smaller warnings set and saves ~10s of runtime on my machine.
## Changelog:
[INTERNAL] [FIXED] - Add `/vendor` to excluded paths for spellcheck script.
Pull Request resolved: https://github.com/facebook/react-native/pull/55020
Test Plan: Running `yarn spellcheck` locally.
Reviewed By: cipolleschi
Differential Revision: D90104078
Pulled By: cortinico
fbshipit-source-id: 9c16a71616a13db1c217b917a498ff8f6a462799
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54865
Removes introduced in D88654826, replaced with a `git fetch` with `--depth`.
This should fix CI runs on `main` (where we believe the extra checkout is clobbering the `yarn-install` step), and improve execution time.
Also shorten action name.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D89044330
fbshipit-source-id: 690eb5c7db9490e5f160e933d64eae6ac21464c8
Summary:
Updates the `diff-js-api-breaking-changes` action to compare the PR's changes against the merge base (where the branch diverged from main) instead of the current tip of main.
### Problem
The previous implementation compared the current state of `main` to the PR head. This could produce false positive results when main had new commits to reactNativeApi.d.ts reporting breaking changes from main as if they were introduced by the PR.
### Solution
- Calculate the merge base between the PR head and `origin/main`
- Compare the API snapshot at the merge base to the snapshot at the PR head
## Changelog:
[GENERAL] [FIXED] - Updates the `diff-js-api-breaking-changes` action to compare the PR's changes against the merge base (where the branch diverged from main) instead of the current tip of main.
Pull Request resolved: https://github.com/facebook/react-native/pull/54819
Test Plan:
(outputs shown for https://github.com/facebook/react-native/pull/54815)
Tested locally on branch that previously got false positive:
Mirror old approach:
```
mkdir -p /tmp/api-diff-old
git show origin/main:packages/react-native/ReactNativeApi.d.ts > /tmp/api-diff-old/before.d.ts
git show HEAD:packages/react-native/ReactNativeApi.d.ts > /tmp/api-diff-old/after.d.ts
node ./scripts/js-api/diff-api-snapshot /tmp/api-diff-old/before.d.ts /tmp/api-diff-old/after.d.ts
```
output:
```
{
"result": "BREAKING",
"changedApis": [
"ActivityIndicatorProps",
"Animated",
"DrawerLayoutAndroidProps",
"FlatList",
"FlatListProps",
"ImageBackground",
"ImageBackgroundProps",
"ImageProps",
"ImagePropsBase",
"KeyDownEvent",
"KeyEvent",
"KeyUpEvent",
"KeyboardAvoidingView",
"KeyboardAvoidingViewProps",
"ModalProps",
"PressableProps",
"ProgressBarAndroidProps",
"RefreshControl",
"RefreshControlProps",
"ScrollViewProps",
"SectionList",
"SectionListProps",
"SwitchProps",
"TextInputProps",
"ViewProps",
"VirtualizedListProps",
"VirtualizedSectionListProps"
]
}
```
Mirror new approach:
```
git fetch origin main
MERGE_BASE=$(git merge-base HEAD origin/main)
echo "Merge base: $MERGE_BASE"
mkdir -p /tmp/api-diff
git show $MERGE_BASE:packages/react-native/ReactNativeApi.d.ts > /tmp/api-diff/before.d.ts
git show HEAD:packages/react-native/ReactNativeApi.d.ts > /tmp/api-diff/after.d.ts
node ./scripts/js-api/diff-api-snapshot /tmp/api-diff/before.d.ts /tmp/api-diff/after.d.ts
```
output:
```
{
"result": "NON_BREAKING",
"changedApis": []
}
```
Reviewed By: huntie
Differential Revision: D88654826
Pulled By: emily8rown
fbshipit-source-id: 5dc2e295d7d527899b5cb6a643c4878aeebf7f0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54634
CI fails after attempting to update to Node v24 (latest LTS) because our `dev-middleware` dev-only dependency `selfsigned` uses a default key size incompatible with the version of OpenSSL in Node>=24.5. We see lots of:
```
error:0A00018F:SSL routines::ee key too small
```
This was mitigated in OSS CI by pinning our Node tests to before v24.5: https://github.com/facebook/react-native/pull/53013
This default is raised upstream in bf687c80cf , this bumps to v4 which includes that fix, and removes the temporary mitigation above.
Changelog:
[Internal]
Reviewed By: cipolleschi
Differential Revision: D87643898
fbshipit-source-id: f1072c0801769d5fcd4bb53f68999653c6dad29f
Summary:
Adds a new action that will run every day after the nightly build is published. This action will set up a blank app from the template, enable Hermes V1, and run a simple E2E test on Android and iOS in both Debug and Release configurations.
## Changelog:
[INTERNAL] [ADDED] - Added basic E2E tests for Hermes V1
Pull Request resolved: https://github.com/facebook/react-native/pull/54576
Test Plan: I haven't tested the changes since they require larger action runners, but the changes are additive and don't impact existing infra (besides adding an optional parameter).
Reviewed By: cortinico
Differential Revision: D87331639
Pulled By: j-piasecki
fbshipit-source-id: 8d26cb7df66f2588b49f86f01ff0b623501e7f2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54567
This change fix a syntax error in the create-draft-release workflow. We were basically passing the Hermes and HermesV1 versions without wrapping them in `'`.
JS was interpreting them as numbers and making a mess of the syntax.
Wrapping them in `'` should fix the job.
The commit was already picked in the release branch.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D87244325
fbshipit-source-id: b115c233779b36a1b6b0462eb0a8ef60ceafce7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54557
When running a release, we are observing failures due to the Meta CLA check failings for commits pushed by our own CI.
The secrets are inherited by the jobs, but we observed that the repository is not checked out with the right token.
This change should fix that.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D87218058
fbshipit-source-id: 8955719ab26e568215f64841fd8d9526c4837f8f
Summary:
After moving to SwiftPM, we stopped testing the build from source using Cocoapods and dynamic frameworks. Given that the migration will take some more time, this change reintroduces a job to keep the build from source using dynamic frameworks in check
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/54482
Test Plan: GHA
Reviewed By: javache
Differential Revision: D86760336
Pulled By: cipolleschi
fbshipit-source-id: c131af44209de40f2ee7f7d08fa61d88aa48d3ee
Summary:
Setting `ENV['RCT_USE_PREBUILT_RNCORE'] = '1'` when running nightlies on iOS will result in the following error:
<img height="608" alt="image" src="https://github.com/user-attachments/assets/130112d7-d4d8-4934-be56-c020a4b204a6" />
The reason for this happening is that we precompile the iOS artifacts on CI using whatever version is set on main (by default version 1000). This works fine when using RCs and stable versions because before the publishing step we do a release commit (e.g 57ff54492f), which updates the react-native version.
This can be easily mitigated by invoking the `set-rn-artifacts-version` CLI right before building the iOS prebuilds.
## Changelog:
[IOS] [FIXED] - Fix iOS version mismatch when using nightly prebuilds
Pull Request resolved: https://github.com/facebook/react-native/pull/54370
Test Plan: Run `node ./scripts/releases/set-rn-artifacts-version.js --build-type` locally
Reviewed By: javache
Differential Revision: D86089144
Pulled By: cipolleschi
fbshipit-source-id: a5c296ea8e022e562f7898803ab37dc61ffd67b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54313
This change updates the draft release workflow to add dSYMS for Hermes V1 and also updating the url from where the dSYMs can be downloaded.
## Changelog:
[Internal] -
Reviewed By: j-piasecki
Differential Revision: D85758123
fbshipit-source-id: 7d771266de5b3829e9a39c649b610aaf79aa6206
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54257
When moving Hermes to the Hermes repo, we mistakenly updated the nightly and the publish_release job to depend on an non-existing job
## Changelog:
[Internal] - Fix CI jobs for nightlies and releases
Reviewed By: huntie
Differential Revision: D85422837
fbshipit-source-id: 18d4ef73c80032b55f09f27e4b58b399f0a148c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53837
Changelog: [Internal]
Replaces usage of Hermes built inside the React Native repository with the release published from the Hermes repo.
Reviewed By: cipolleschi
Differential Revision: D82721725
fbshipit-source-id: 357d5e2b914675ec6e60f810c382a945aa461732
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53817
What is currently happening, is that the various commits on the release branches like `0.82-stable` are resetting the version of native artifacts to `1000.0.0-<SHA>`.
The reason is that during the `test-all` workflow, we pass the `dry-run` as release type.
That's to prevent the various tools from calling `npm publish` and so on.
The problem is that on the releases branches, the version was already set at branch cut time.
Therefore, we see the version 1000.0.0 reappearing during Android E2E test in the emulator. Similary this is also affecting iOS prebuilds so I'm attempting to fix it here.
Changelog:
[Internal] [Changed] -
Reviewed By: huntie
Differential Revision: D82553599
fbshipit-source-id: 31a52e7df036e700663b3d3dd677973a7a210a30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53795
I've published another docker image that should now work and unblock `run_fantom_tests`
so we don't need to pin the version to `v18.0` anymore:
https://github.com/react-native-community/docker-android
Changelog:
[Internal] [Changed] -
Reviewed By: huntie
Differential Revision: D82532516
fbshipit-source-id: 980c2feb053f9d096e70f37bb690e18cc8b87dc0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53715
This is a backport of ee08261123
on `main` as otherwise 0.83 will also be affected by the same problem (CI broken for iOS on the release branch).
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D82119125
fbshipit-source-id: 6fbdcd42b446bd49ac71bbe834181ba91cc67990
Summary:
We had reports from the Community of the RN CI running on forks and causing high costs and bills for them
This change should make sure that the most impactful jobs only runs on the React Native CI and not on forks.
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/53707
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D82107313
Pulled By: cipolleschi
fbshipit-source-id: ff7f418344975e7bb8306a6356d774c26bea3db1
Summary:
This PR adds additional checks to run nightly jobs only on the main repo.
I noticed pretty heavy usage on my fork of React Native:
<img width="951" height="179" alt="Screenshot 2025-09-10 at 11 47 29" src="https://github.com/user-attachments/assets/91cb9e4a-8658-42bd-bbfe-ffba01b0b3b3" />
I also noticed a typo in this file with output instead of outputs
## Changelog:
[INTERNAL] [FIXED] - add conditional checks for facebook/react-native repo for nightly workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/53700
Test Plan: Check if the syntax is correct.
Reviewed By: cortinico
Differential Revision: D82104958
Pulled By: cipolleschi
fbshipit-source-id: fc2e6e0299345ebd115c7a574a5a8161f2b0ca5c
Summary:
bypass-github-export-checks
OSS release infrastructure for the (experimental) React Native DevTools standalone shell.
Currently, binaries are built continuously on Meta infra and served from the Meta CDN using fbcdn.net URLs checked into a DotSlash file in the repo, e.g.:
15373218ec/packages/debugger-shell/bin/react-native-devtools (L9-L18)
For open source releases we want to primarily distribute the binaries as GitHub release assets, while keeping the Meta CDN URLs as a secondary option. This PR makes the necessary changes to the release workflows to support this:
* `workflows/create-release.yml` (modified): As part of the release commit, rewrite the DotSlash file to include the release asset URLs.
* **NOTE:** After this commit, **the new URLs don't work yet**, because they refer to a release that hasn't been published. Despite this, the DotSlash file remains valid and usable (because DotSlash will happily fall back to the Meta CDN URLs, which are still in the file).
* `workflows/create-draft-release.yml` (modified): After creating a draft release, fetch the binaries from the Meta CDN and reupload them to GitHub as release assets. This is based on the contents of the DotSlash file rewritten by `create-release.yml`.
* `workflows/validate-dotslash-artifacts.yml` (new): After the release is published, all URLs referenced by the DotSlash (both Meta CDN URL and GH release asset URLs) should be valid and refer to the same artifacts. This workflow checks that this is the case.
* If this workflow fails on a published release, the release may need to be burned or a hotfix release may be necessary - as the release will stop working correctly once the Meta CDN stops serving the assets.
* This workflow will also be running continuously on `main`. If it fails on a commit in `main`, there might be a connectivity issue between the GHA runner and the Meta CDN, or there might be an issue on the Meta side.
NOTE: These changes to the release pipeline are generic and reusable; if we later add another DotSlash-based tool whose binaries need to be mirrored as GitHub release assets, we just need to add it to the `FIRST_PARTY_DOTSLASH_FILES` array.
## Changelog:
[Internal] Mirror React Native DevTools binaries in GitHub Releases
Pull Request resolved: https://github.com/facebook/react-native/pull/52930
Test Plan:
### Step 0: Unit tests
I've added unit tests for `dotslash-utils`, `curl-utils`, and for the majority of the logic that makes up the new release scripts (`write-dotslash-release-assets-urls`, `upload-release-assets-for-dotslash`, `validate-dotslash-artifacts`).
### Step 1: Test release commit
Created a test branch and draft PR: https://github.com/facebook/react-native/pull/53147.
Locally created a release commit, simulating the create-release GH workflow:
```
node scripts/releases/create-release-commit.js --reactNativeVersion 0.82.0-20250903-0830 --no-dry-run
```
This updated the DotSlash file in the branch: 2deeb7e703 (diff-205a9ff6005e30be061eaa64b9cb50b15b0e909dd188e0866189e952655a3483)
NOTE: I've also ensured that the `create-release-commit` script correctly updates the DotSlash file when running from a branch that already has a release commit - see screenshot:
<img width="1483" height="587" alt="image" src="https://github.com/user-attachments/assets/1ffd859b-e02b-483d-8067-9cc9116829a4" />
### Step 2: Test draft release
Enabled testing the create-draft-release GH workflow in the test branch using these temporary hacks:
* 81f334eac5
* 6d88516576
* 1428a8da8b
Workflow run: https://github.com/facebook/react-native/actions/runs/17426711373/job/49475327346
Draft release: https://github.com/facebook/react-native/releases/tag/untagged-c6a62a58e5baa37936e1
Draft release screenshot for posterity (since we'll likely delete the draft release after landing this):
<img width="1024" height="814" alt="image" src="https://github.com/user-attachments/assets/1900da15-48f6-4274-b29c-0ac2019d92c0" />
### Step 3: Test post-release validation script
For obvious reasons, I've avoided actually publishing the above draft release. But I have run the `validate-dotslash-artifacts` workflow on the *current* branch to ensure that the logic is correct: https://github.com/motiz88/react-native/actions/runs/17426885205/job/49475888486
Running `node scripts/releases/validate-dotslash-artifacts.js` in the release branch (without publishing the release first) fails, as expected:
<img width="1105" height="748" alt="image" src="https://github.com/user-attachments/assets/ed23a2e2-7a31-42eb-a324-f1d50eafe2fb" />
## Next steps
This PR is all the infra needed ahead of the 0.82 ~~branch cut~~ infra freeze to support the React Native DevTools standalone shell, at least on the GitHub side. ~~Some minor infra work remains on the Meta side, plus some product/logic changes to the React Native DevTools standalone shell that I'm intending to finish in time for 0.82 (for an experimental rollout).~~ EDIT: All the planned work has landed; the feature is code-complete on `main` as well as in `0.82-stable` (apart from this infra change).
As a one-off, once we've actually published 0.82.0-rc.1, we'll want to have a human look at the published artifacts and CI workflow logs to ensure everything is in order. (I'll make sure to communicate this to the 0.82 release crew.) Afterwards, the automation added in this PR should be sufficient.
Reviewed By: huntie
Differential Revision: D81578704
Pulled By: motiz88
fbshipit-source-id: 6a4a48c3713221a89dd5fc88851674c1ddc6bb10
Summary:
Symbol files wasn't copied correctly when building - as with bundles we did overwrite the files and ended up with only the last symbol file.
This commit fixes this by mapping the framework build folder architecture type to the xcframework slices creating the correct file structure under the Symbols folder.
- Each slice gets a folder with the architecture name under Symbols containing the dSym folder for that slice
- Refactored getting correct architecture folder into a separate function.
- Refactored target folder lookup in copyBundles
- Removed unused async modifier on function
## Changelog:
[IOS] [FIXED] - Fixed how we copy and build the Symbols folder when precompiling ReactNativeDependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/53353
Test Plan: Run nightlies and verify that ReactNativeDependencies.framework.dSym files contains symbol files for all architectures.
Reviewed By: cortinico
Differential Revision: D80692019
Pulled By: cipolleschi
fbshipit-source-id: 77983bc29d1965edf3bc0fcbd9cb3177071991d3
