Distribute React Native DevTools binaries via GitHub Releases #52930

motiz88 · 2025-07-31T09:30:09Z

Summary:

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.:

react-native/packages/debugger-shell/bin/react-native-devtools

Lines 9 to 18 in 1537321

    
           "linux-aarch64": { 
        
               "size": 113511487, 
        
               "hash": "sha256", 
        
               "digest": "c22f7d5e029357f05055ce7c56cc284a0d441d558e103a7b7ebae118c67d0b95", 
        
               "providers": [ 
        
                   { 
        
                       "type": "http", 
        
                       "url": "https://scontent.xx.fbcdn.net/mci_ab/uap/?ab_b=m&ab_page=react_native_devtools_binaries&ab_entry=AQPRilWDJV8xyKEv9lqYn7Hf2kyZg6nqW8KctGZCXsU95lS_MTFyAmEULrB3J6hGCjqBY2Zl-uq_FjERAIgzbZFWX2eceacTbutBSOKEj6QTZzkVN_L1zPh2lGh24x29MHpkwUzw4E-kAXV43f-11QxqD7orI1QicyOnsmUqeRNKE_QjM9rNRsw6iE8" 
        
                   } 
        
               ],

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

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: #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: 2deeb7e#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:

Step 2: Test draft release

Enabled testing the create-draft-release GH workflow in the test branch using these temporary hacks:

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):

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:

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.

cipolleschi

I left some comments.
The PR is quite big, it would be nice to split it in smaller parts.

cipolleschi · 2025-08-11T09:25:05Z

.github/workflow-scripts/createDraftRelease.js

    token,
  );
-  log(`Created draft release: ${release}`);
+  log(`Created draft release: ${release.html_url}`);


nit: does it make sense to also log the id, for debugging purposes?

.github/workflows/create-draft-release.yml

cipolleschi · 2025-08-11T09:26:41Z

.github/workflows/create-draft-release.yml

+            await uploadReleaseAssetsForDotSlash({
+              version,
+              token: '${{secrets.REACT_NATIVE_BOT_GITHUB_TOKEN}}',
+              releaseId: process.env.RELEASE_ID,


Suggested change

releaseId: process.env.RELEASE_ID,

releaseId: ${{ steps.create-draft-release.outputs.result }}

scripts/releases/upload-release-assets-for-dotslash.js

scripts/releases/write-dotslash-release-asset-urls.js

cortinico

Great stuff! :)
If we could have this PR split in smaller one woudl be ideal

cortinico · 2025-08-11T14:02:29Z

.github/workflows/validate-dotslash-artifacts.yml

+  push:
+    branches:
+      - main


This feels wrong, are you sure about it?

It turns out it's correct. Still I'm not 100% sure why we would need to run a continous validation of the dotslash artifacts. Specifically, this is a job that will run on main (also, why not on PRs also then) and that is heavily dependent on network, so it could result in a lot of red signals for us

Running on PRs targeting main is reasonable - it's just largely unnecessary, because we're only going to be touching the DotSlash files in bot commits that will be auto-landed in fbsource and then exported to the main branch.

To reduce the false positive rate, we could narrow this down further to commits that actually touch the DotSlash file(s), though of course that could miss infra changes in the repo that might break the workflow.

The scenario I'm trying to prevent is one where our internal binary publishing pipeline / CDN gets broken and stops being accessible from OSS, but we only find out extremely late, when we try to create a release commit. (As explained in the summary, we can't run the validation continuously in the branch because it would fail - by design - between pushing the release commit and publishing the release).

(As explained in the summary, we can't run the validation continuously in the branch because it would fail - by design - between pushing the release commit and publishing the release).

Let's let it run only on *-stable branches then?

Let's let it run only on *-stable branches then?

That's not feasible, unless we're OK with letting the job fail on release commits (and in fact tagging the release on a commit that has red CI signals!)

The scenario I'm trying to prevent is one where our internal binary publishing pipeline / CDN gets broken and stops being accessible from OSS, but we only find out extremely late, when we try to create a release commit.

Hmm, what about on nightlies instead?

Oh interesting. I don't know that we want to block nightlies on this - doesn't look like we do so when another kind of test is broken - but I'm definitely open to making this a scheduled job for periodic validation, plus running on pushes+PRs that touch the actual DotSlash file and related infra. WDYT?

See 5b02181.

scripts/releases/utils/curl-utils.js

scripts/releases/upload-release-assets-for-dotslash.js

package.json

motiz88 · 2025-08-19T10:43:19Z

Re: splitting this PR - this is really the smallest version of the PR that allows the overall solution to be reviewed (and tested end-to-end), especially with the lack of support for stacks on GH. I'm happy to work on making the code clearer for ease of review, but splitting it into separate branches would likely result in more bugs IMO.

cortinico · 2025-08-19T11:30:45Z

especially with the lack of support for stacks on GH

You can either create a PR with several commits, or several chained PRs to help with this.

motiz88 · 2025-08-19T14:50:07Z

@cortinico I can definitely flatten the commit history in this PR a bit more now that it's functionally complete. There would be 3-4 logical commits (one for each modified workflow and probably one for shared utilities) which should be easier to review one by one.

motiz88 · 2025-09-02T16:08:29Z

@cipolleschi, @cortinico: I've addressed feedback and done a deep refactoring pass for ease of review (smaller and more readable functions, extensive tests, logical commits each with its own summary).

Summary: Adds some reusable Jest snapshot serializers used later in this PR.

Summary: Adds the `write-dotslash-release-asset-urls` script and hooks it up to the `create-release-commit` script. After this script runs, the branch will reference GitHub release assets that haven't been uploaded yet - this is necessary because we publish the branch to npm before we ever create a draft GitHub release we can upload things to. In a separate commit in this PR, we will augment the `create-draft-release` workflow to actually upload the assets, based on the contents of the release commit. Comes with unit tests.

Summary: Augments the `create-draft-release` workflow to upload GitHub release assets referenced by the first-party DotSlash files in the repo, based on the output of `create-release-commit`. Comes with unit tests.

Summary: Adds a workflow to ensure the following: * Continuously: `main` contains valid DotSlash files that reference valid artifacts. * When a release is published: the release contains valid DotSlash files that reference valid artifacts. This gives us confidence that branch cuts start in a valid state and that releases go out in a valid state. This is particularly important since there is a span of time, between the release commit and the publishing of the GH release, when the job would fail (as the release assets are not hosted at their final URLs yet). This is a fairly trivial script built on top of unit-tested utilities: `processDotSlashFileInPlace`, `getWithCurl`, `validateDotSlashArtifactData`.

motiz88 · 2025-09-03T14:43:46Z

Added types for @octokit/rest (partial types only), jsonc-parser and @expo/spawn-async and fb-dotslash. These actually help with importing the PR to fbsource, since the internal Flow config behaves differently when dealing with node_modules that don't have in-repo definition files.

facebook-github-bot · 2025-09-03T14:46:31Z

@motiz88 has imported this pull request. If you are a Meta employee, you can view this in D81578704.

facebook-github-bot · 2025-09-03T14:58:08Z

@motiz88 has imported this pull request. If you are a Meta employee, you can view this in D81578704.

motiz88 · 2025-09-03T17:15:15Z

Meta employees: see D81592612 for the internal fixups on top of this PR to make CI green. I'll squash them into D81578704 after the GitHub review is finished, to keep this branch as the source of truth for now.

huntie · 2025-09-04T09:04:23Z

scripts/releases/validate-dotslash-artifacts.js

+  valid URLs that return the described artifacts. This script is intended to run
+  in two key scenarios:
+
+  1. Continuously on main - this verifies the output of the Meta-internal CI pipeline


huntie · 2025-09-04T09:16:01Z

.github/workflows/validate-dotslash-artifacts.yml

+  push:
+    branches:
+      - main


The scenario I'm trying to prevent is one where our internal binary publishing pipeline / CDN gets broken and stops being accessible from OSS, but we only find out extremely late, when we try to create a release commit.

Hmm, what about on nightlies instead?

…trigger

facebook-github-bot · 2025-09-04T10:11:36Z

@motiz88 has imported this pull request. If you are a Meta employee, you can view this in D81578704.

huntie

LGTM, happy in one diff and with the change to nightly runs :)

Summary: We were using `--write-out %{header_json}` but this feature requires curl 7.83.0. Some of our CI environments have an older version of curl so we need a different approach.

facebook-github-bot · 2025-09-04T11:25:39Z

@motiz88 has imported this pull request. If you are a Meta employee, you can view this in D81578704.

facebook-github-bot · 2025-09-04T18:34:48Z

@motiz88 merged this pull request in 1f57ae5.

react-native-bot · 2025-09-04T18:34:50Z

This pull request was successfully merged by @motiz88 in 1f57ae5

^{When will my fix make it into a release? | How to file a pick request?}

…ok#52930) 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.: https://github.com/facebook/react-native/blob/15373218ec572c0e43325845b80a849ad5174cc3/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. [Internal] Mirror React Native DevTools binaries in GitHub Releases Pull Request resolved: facebook#52930 Test Plan: 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`). Created a test branch and draft PR: facebook#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: facebook@2deeb7e#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" /> Enabled testing the create-draft-release GH workflow in the test branch using these temporary hacks: * facebook@81f334e * facebook@6d88516 * facebook@1428a8d 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" /> 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" /> 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

#53604) 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.: https://github.com/facebook/react-native/blob/15373218ec572c0e43325845b80a849ad5174cc3/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. [Internal] Mirror React Native DevTools binaries in GitHub Releases Pull Request resolved: #52930 Test Plan: 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`). Created a test branch and draft PR: #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: 2deeb7e#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" /> Enabled testing the create-draft-release GH workflow in the test branch using these temporary hacks: * 81f334e * 6d88516 * 1428a8d 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" /> 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" /> 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

react-native-bot · 2025-09-08T13:20:05Z

This pull request was successfully merged by @motiz88 in fdc4da9

^{When will my fix make it into a release? | How to file a pick request?}

meta-cla bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jul 31, 2025

facebook-github-bot added p: Facebook Partner: Facebook Partner labels Jul 31, 2025

motiz88 force-pushed the rndt-binaries-to-release-assets branch from daa25bf to 9fbe3bf Compare August 7, 2025 16:44

motiz88 mentioned this pull request Aug 7, 2025

[DRAFT][NOT FOR MERGING] Test branch for #52930 #53146

Closed

motiz88 force-pushed the rndt-binaries-to-release-assets branch 2 times, most recently from 9773024 to c59042a Compare August 7, 2025 17:23

motiz88 mentioned this pull request Aug 7, 2025

[DRAFT][NOT FOR MERGING] Test branch for #52930 #53147

Draft

motiz88 force-pushed the rndt-binaries-to-release-assets branch 3 times, most recently from 0f87802 to a4c2f83 Compare August 8, 2025 17:51

motiz88 requested review from cipolleschi and cortinico August 8, 2025 21:13

motiz88 marked this pull request as ready for review August 8, 2025 21:13

motiz88 changed the title ~~[DRAFT] Distribute React Native DevTools binaries via GitHub Releases~~ Distribute React Native DevTools binaries via GitHub Releases Aug 8, 2025

facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Aug 8, 2025

motiz88 mentioned this pull request Aug 9, 2025

feat: create npm package facebook/dotslash#74

Closed

9 tasks

cipolleschi approved these changes Aug 11, 2025

View reviewed changes

cortinico requested changes Aug 11, 2025

View reviewed changes

motiz88 force-pushed the rndt-binaries-to-release-assets branch 6 times, most recently from 7db1656 to e1dc194 Compare September 2, 2025 15:59

motiz88 requested a review from cortinico September 2, 2025 15:59

motiz88 and others added 7 commits September 3, 2025 15:33

Jest snapshot utils

e090b2a

Summary: Adds some reusable Jest snapshot serializers used later in this PR.

Upload first-party DotSlash binary assets to draft releases

3d13133

Summary: Augments the `create-draft-release` workflow to upload GitHub release assets referenced by the first-party DotSlash files in the repo, based on the output of `create-release-commit`. Comes with unit tests.

Improve typing of Octokit

359411e

Add types for @expo/spawn-async

5429325

Add types for jsonc-parser

1c2fbb8

motiz88 force-pushed the rndt-binaries-to-release-assets branch from a6f8246 to 1c2fbb8 Compare September 3, 2025 14:33

Add Flow libdef for fb-dotslash

843f561

motiz88 force-pushed the rndt-binaries-to-release-assets branch from 4a4afa8 to 843f561 Compare September 3, 2025 14:56

huntie reviewed Sep 4, 2025

View reviewed changes

Limit scope of validate-dotslash-artifacts push trigger, add nightly …

5b02181

…trigger

huntie approved these changes Sep 4, 2025

View reviewed changes

Make getWithCurl compatible with older curl

df892eb

Summary: We were using `--write-out %{header_json}` but this feature requires curl 7.83.0. Some of our CI environments have an older version of curl so we need a different approach.

facebook-github-bot closed this in 1f57ae5 Sep 4, 2025

facebook-github-bot added the Merged This PR has been merged. label Sep 4, 2025

motiz88 mentioned this pull request Sep 4, 2025

[0.82] Distribute React Native DevTools binaries via GitHub Releases #53604

Merged

motiz88 mentioned this pull request Sep 10, 2025

Add workflow to backfill assets for a manual/incomplete GitHub release #53701

Open

	"linux-aarch64": {
	"size": 113511487,
	"hash": "sha256",
	"digest": "c22f7d5e029357f05055ce7c56cc284a0d441d558e103a7b7ebae118c67d0b95",
	"providers": [
	{
	"type": "http",
	"url": "https://scontent.xx.fbcdn.net/mci_ab/uap/?ab_b=m&ab_page=react_native_devtools_binaries&ab_entry=AQPRilWDJV8xyKEv9lqYn7Hf2kyZg6nqW8KctGZCXsU95lS_MTFyAmEULrB3J6hGCjqBY2Zl-uq_FjERAIgzbZFWX2eceacTbutBSOKEj6QTZzkVN_L1zPh2lGh24x29MHpkwUzw4E-kAXV43f-11QxqD7orI1QicyOnsmUqeRNKE_QjM9rNRsw6iE8"
	}
	],

	releaseId: process.env.RELEASE_ID,
	releaseId: ${{ steps.create-draft-release.outputs.result }}

Distribute React Native DevTools binaries via GitHub Releases #52930

Distribute React Native DevTools binaries via GitHub Releases #52930

Uh oh!

Conversation

motiz88 commented Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary:

Changelog:

Test Plan:

Step 0: Unit tests

Step 1: Test release commit

Step 2: Test draft release

Step 3: Test post-release validation script

Next steps

Uh oh!

cipolleschi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cortinico left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

motiz88 Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

motiz88 commented Aug 19, 2025

Uh oh!

cortinico commented Aug 19, 2025

Uh oh!

motiz88 commented Aug 19, 2025

Uh oh!

motiz88 commented Sep 2, 2025

Uh oh!

motiz88 commented Sep 3, 2025

Uh oh!

facebook-github-bot commented Sep 3, 2025

Uh oh!

facebook-github-bot commented Sep 3, 2025

Uh oh!

motiz88 commented Sep 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

facebook-github-bot commented Sep 4, 2025

Uh oh!

huntie left a comment

Choose a reason for hiding this comment

Uh oh!

facebook-github-bot commented Sep 4, 2025

motiz88 commented Jul 31, 2025 •

edited

Loading

motiz88 Sep 4, 2025 •

edited

Loading