react-native-macos/.circleci/config.yml

1760 строки
62 KiB
YAML
Исходник Обычный вид История

version: 2.1
# -------------------------
# ORBS
# -------------------------
orbs:
win: circleci/windows@2.4.0
# -------------------------
# REFERENCES
# -------------------------
references:
defaults: &defaults
working_directory: ~/react-native
environment:
- GIT_COMMIT_DESC: git log --format=oneline -n 1 $CIRCLE_SHA1
# The public github tokens are publicly visible by design
- PUBLIC_PULLBOT_GITHUB_TOKEN_A: &github_pullbot_token_a "a6edf8e8d40ce4e8b11a"
- PUBLIC_PULLBOT_GITHUB_TOKEN_B: &github_pullbot_token_b "150e1341f4dd9c944d2a"
- PUBLIC_ANALYSISBOT_GITHUB_TOKEN_A: &github_analysisbot_token_a "312d354b5c36f082cfe9"
- PUBLIC_ANALYSISBOT_GITHUB_TOKEN_B: &github_analysisbot_token_b "07973d757026bdd9f196"
# Homebrew currently breaks while updating:
# https://discuss.circleci.com/t/brew-install-fails-while-updating/32992
- HOMEBREW_NO_AUTO_UPDATE: 1
hermes_workspace_root: &hermes_workspace_root
/tmp/hermes
hermes_tarball_artifacts_dir: &hermes_tarball_artifacts_dir
/tmp/hermes/hermes-runtime-darwin
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
hermes_osxbin_artifacts_dir: &hermes_osxbin_artifacts_dir
/tmp/hermes/osx-bin
attach_hermes_workspace: &attach_hermes_workspace
attach_workspace:
at: *hermes_workspace_root
# -------------------------
# Dependency Anchors
# -------------------------
dependency_versions:
xcode_version: &xcode_version "14.0.1"
nodelts_image: &nodelts_image "cimg/node:16.14"
nodeprevlts_image: &nodeprevlts_image "cimg/node:14.19"
# -------------------------
# Cache Key Anchors
# -------------------------
# Anchors for the cache keys
cache_keys:
checkout_cache_key: &checkout_cache_key v1-checkout
gems_cache_key: &gems_cache_key v1-gems-{{ checksum "Gemfile.lock" }}
gradle_cache_key: &gradle_cache_key v1-gradle-{{ checksum "gradle/wrapper/gradle-wrapper.properties" }}-{{ checksum "ReactAndroid/gradle.properties" }}
hermes_workspace_cache_key: &hermes_workspace_cache_key v4-hermes-{{ .Environment.CIRCLE_JOB }}-{{ checksum "/tmp/hermes/hermesversion" }}
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
hermes_workspace_debug_cache_key: &hermes_workspace_debug_cache_key v2-hermes-{{ .Environment.CIRCLE_JOB }}-debug-{{ checksum "/tmp/hermes/hermesversion" }}
hermes_workspace_release_cache_key: &hermes_workspace_release_cache_key v2-hermes-{{ .Environment.CIRCLE_JOB }}-release-{{ checksum "/tmp/hermes/hermesversion" }}
hermes_windows_cache_key: &hermes_windows_cache_key v3-hermes-{{ .Environment.CIRCLE_JOB }}-{{ checksum "tmp/hermes/hermesversion" }}
hermes_tarball_debug_cache_key: &hermes_tarball_debug_cache_key v2-hermes-tarball-debug-{{ checksum "/tmp/hermes/hermesversion" }}
hermes_tarball_release_cache_key: &hermes_tarball_release_cache_key v1-hermes-tarball-release-{{ checksum "/tmp/hermes/hermesversion" }}
pods_cache_key: &pods_cache_key v8-pods-{{ .Environment.CIRCLE_JOB }}-{{ checksum "packages/rn-tester/Podfile.lock.bak" }}-{{ checksum "packages/rn-tester/Podfile" }}
windows_yarn_cache_key: &windows_yarn_cache_key v1-win-yarn-cache-{{ arch }}-{{ checksum "yarn.lock" }}
yarn_cache_key: &yarn_cache_key v5-yarn-cache-{{ .Environment.CIRCLE_JOB }}
cache_paths:
hermes_workspace_macos_cache_paths: &hermes_workspace_macos_cache_paths
- ~/react-native/sdks/hermes/build_macosx
- ~/react-native/sdks/hermes/destroot
hermes_tarball_cache_paths: &hermes_tarball_cache_paths
- *hermes_tarball_artifacts_dir
# -------------------------
# Filters
# -------------------------
# CircleCI filters are OR-ed, with all branches triggering by default and tags excluded by default
# CircleCI env-vars are only set with the branch OR tag that triggered the job, not both.
# In this case, CIRCLE_BRANCH is unset, but CIRCLE_TAG is set.
only_release_tags: &only_release_tags
# Both of the following conditions must be included!
# Ignore any commit on any branch by default.
branches:
ignore: /.*/
# Only act on version tags.
tags:
only: /v[0-9]+(\.[0-9]+)*(\-rc(\.[0-9]+)?)?/
# -------------------------
# EXECUTORS
# -------------------------
executors:
nodelts:
<<: *defaults
docker:
Use Node v14 in Windows CircleCI jobs (#31656) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/31656 CircleCI's Windows executor currently ships with a pre-LTS release of Node v12, breaking our Windows jobs ([example](https://app.circleci.com/pipelines/github/facebook/react-native/9280/workflows/21e6e59c-d853-47a1-af62-1368c8ce10ce/jobs/203983)) following https://github.com/facebook/react-native/pull/30637, ultimately due to https://github.com/facebook/jest/pull/10685 dropping support for non-LTS versions in the Node v12 release line. Luckily, the Windows executor [does ship with nvm](https://github.com/circleci/circleci-docs/issues/3733) so we can use that to install a desired Node version. Rather than just pinning a later v12 release that is LTS, we pin a v14 release that is currently the most recent LTS version. NOTE: The nvm on CircleCI is https://github.com/coreybutler/nvm-windows, not https://github.com/nvm-sh/nvm, and the two aren't interchangeable. [nvm-windows has no functionality to install the latest version of a release line](https://github.com/coreybutler/nvm-windows/issues/156) so we're forced to specify an exact version, which will need to be bumped manually in the future. This isn't great, but IMO it's no worse than the current situation, where we use whichever stale version of Node happens to be bundled with the Windows CircleCI executor. Changelog: [Internal] Reviewed By: GijsWeterings Differential Revision: D28896581 fbshipit-source-id: a412376cf36054de49efa49866fe60dd964567c5
2021-06-04 17:18:34 +03:00
# Note: Version set separately for Windows builds, see below.
- image: *nodelts_image
resource_class: "xlarge"
nodeprevlts:
<<: *defaults
docker:
- image: *nodeprevlts_image
resource_class: "xlarge"
reactnativeandroid:
<<: *defaults
docker:
- image: reactnativecommunity/react-native-android:6.0
resource_class: "xlarge"
environment:
- TERM: "dumb"
- ADB_INSTALL_TIMEOUT: 10
- GRADLE_OPTS: '-Dorg.gradle.daemon=false -Dorg.gradle.jvmargs="-XX:+HeapDumpOnOutOfMemoryError"'
- BUILD_THREADS: 2
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
# Repeated here, as the environment key in this executor will overwrite the one in defaults
- PUBLIC_ANALYSISBOT_GITHUB_TOKEN_A: *github_analysisbot_token_a
- PUBLIC_ANALYSISBOT_GITHUB_TOKEN_B: *github_analysisbot_token_b
- PUBLIC_PULLBOT_GITHUB_TOKEN_A: *github_pullbot_token_a
- PUBLIC_PULLBOT_GITHUB_TOKEN_B: *github_pullbot_token_b
reactnativeios:
<<: *defaults
macos:
xcode: *xcode_version
resource_class: macos.x86.medium.gen2
# -------------------------
# COMMANDS
# -------------------------
commands:
# Checkout with cache, on machines that are using Docker the cache is ignored
checkout_code_with_cache:
parameters:
checkout_base_cache_key:
default: *checkout_cache_key
type: string
steps:
- restore_cache:
keys:
- << parameters.checkout_base_cache_key >>-{{ arch }}-{{ .Branch }}-{{ .Revision }}
- << parameters.checkout_base_cache_key >>-{{ arch }}-{{ .Branch }}-
- << parameters.checkout_base_cache_key >>-{{ arch }}-
- checkout
- save_cache:
key: << parameters.checkout_base_cache_key >>-{{ arch }}-{{ .Branch }}-{{ .Revision }}
paths:
- ".git"
setup_artifacts:
steps:
- run:
name: Initial Setup
command: mkdir -p ./reports/{buck,build,junit,outputs}
setup_ruby:
steps:
- restore_cache:
key: *gems_cache_key
- run:
name: Bundle Install
command: |
source /usr/local/share/chruby/auto.sh
bundle check || bundle install --path vendor/bundle --clean
- save_cache:
key: *gems_cache_key
paths:
- vendor/bundle
run_yarn:
parameters:
yarn_base_cache_key:
default: *yarn_cache_key
type: string
steps:
- restore_cache:
keys:
- << parameters.yarn_base_cache_key >>-{{ arch }}-{{ checksum "yarn.lock" }}
- << parameters.yarn_base_cache_key >>-{{ arch }}
- << parameters.yarn_base_cache_key >>
- run:
name: "Yarn: Install Dependencies"
command: |
# Skip yarn install on metro bump commits as the package is not yet
# available on npm
if [[ $(echo "$GIT_COMMIT_DESC" | grep -c "Bump metro@") -eq 0 ]]; then
yarn install --non-interactive --cache-folder ~/.cache/yarn
fi
- save_cache:
paths:
- ~/.cache/yarn
key: << parameters.yarn_base_cache_key >>-{{ arch }}-{{ checksum "yarn.lock" }}
brew_install:
parameters:
package:
description: Homebrew package to install
type: string
steps:
- run:
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
name: "Brew: Install << parameters.package >>"
command: brew install << parameters.package >> >/dev/null
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
with_rntester_pods_cache_span:
parameters:
steps:
type: steps
steps:
- run:
name: Setup CocoaPods cache
# Copy packages/rn-tester/Podfile.lock since it can be changed by pod install
command: cp packages/rn-tester/Podfile.lock packages/rn-tester/Podfile.lock.bak
- restore_cache:
keys:
# The committed lockfile is generated using USE_FRAMEWORKS=0 and USE_HERMES=1 so it could load an outdated cache if a change
2020-12-04 11:23:38 +03:00
# only affects the frameworks or hermes config. To help prevent this also cache based on the content of Podfile.
- *pods_cache_key
- steps: << parameters.steps >>
- save_cache:
paths:
- packages/rn-tester/Pods
key: *pods_cache_key
download_gradle_dependencies:
steps:
- restore_cache:
keys:
- *gradle_cache_key
- run:
name: Download Dependencies Using Gradle
command: ./gradlew downloadAll
- save_cache:
paths:
- ~/.gradle
- ReactAndroid/build/downloads
- ReactAndroid/build/third-party-ndk
key: *gradle_cache_key
run_e2e:
parameters:
platform:
description: Target platform
type: enum
enum: ["android", "ios", "js"]
default: "js"
retries:
description: How many times the job should try to run these tests
type: integer
default: 3
steps:
- run:
name: "Run Tests: << parameters.platform >> End-to-End Tests"
command: node ./scripts/run-ci-e2e-tests.js --<< parameters.platform >> --retries << parameters.retries >>
report_bundle_size:
parameters:
platform:
description: Target platform
type: enum
enum: ["android", "ios"]
steps:
- run:
name: Report size of RNTester.app (analysis-bot)
command: GITHUB_TOKEN="$PUBLIC_ANALYSISBOT_GITHUB_TOKEN_A""$PUBLIC_ANALYSISBOT_GITHUB_TOKEN_B" scripts/circleci/report-bundle-size.sh << parameters.platform >> || true
with_hermes_tarball_cache_span:
parameters:
steps:
type: steps
set_tarball_path:
type: boolean
default: False
flavor:
default: "Debug"
description: The Hermes build type. Must be one of "Debug", "Release".
type: enum
enum: ["Debug", "Release"]
hermes_tarball_artifacts_dir:
type: string
default: *hermes_tarball_artifacts_dir
steps:
- when:
condition:
equal: [ << parameters.flavor >>, "Debug"]
steps:
- restore_cache:
keys:
- *hermes_tarball_debug_cache_key
- when:
condition:
equal: [ << parameters.flavor >>, "Release"]
steps:
- restore_cache:
keys:
- *hermes_tarball_release_cache_key
- when:
condition: << parameters.set_tarball_path >>
steps:
- run:
name: Set HERMES_ENGINE_TARBALL_PATH envvar if Hermes tarball is present
command: |
HERMES_TARBALL_ARTIFACTS_DIR=<< parameters.hermes_tarball_artifacts_dir >>
if [ ! -d $HERMES_TARBALL_ARTIFACTS_DIR ]; then
echo "Hermes tarball artifacts dir not present ($HERMES_TARBALL_ARTIFACTS_DIR). Build Hermes from source."
Reduce flakiness of CI (#34235) Summary: How the Hermes cache worked had a concurrency issue. It used to work by asking the Hermes repository for the latest commit and using that commit as cache key to try and retrieve a built version of Hermes to avoid to compile it more than once. The problem happened when the `build_hermes_macos` was building Hermes using a commit A. While building, another PR could be merged into `hermes:main`, creating commit B. When this happened, the tasks `test_ios` and `test_ios_rntester`would try to retrieve a cached version of Hermes using commit B. That version did not exist because Hermes was created using commit A, and the job would either fail or trying to build Hermes from source, ending up taking a lot of time. This PR attaches the `.hermes-cache-key-file` to the workspace and restores it in the other jobs, making sure that the same cache key is used in all three jobs. ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://reactnative.dev/contributing/changelogs-in-pull-requests --> [General] [Changed] - Attach the `.hermes-cache-key-file` to the workspace to avoid race conditions for new PR landing on Hermes and changing the head commit between the time Hermes is built and the time it has to be consumed. Pull Request resolved: https://github.com/facebook/react-native/pull/34235 Test Plan: Tested manually, looking at the messages in CI. **build_hermes_macos** <img width="881" alt="Screenshot 2022-07-21 at 15 40 02" src="https://user-images.githubusercontent.com/11162307/180241834-776f2291-63bb-4bb2-8837-14434b50fe61.png"> **test_ios_rntester**: notice that the `echo` is not executed, meaning that the `if` does not evaluate to true and, therefore, the file has been correctly attached. <img width="956" alt="Screenshot 2022-07-21 at 15 40 52" src="https://user-images.githubusercontent.com/11162307/180242004-d9db0336-18d3-4321-a997-b538baa6beee.png"> **test_ios**: notice that the `echo` is not executed, meaning that the `if` does not evaluate to true and, therefore, the file has been correctly attached. <img width="900" alt="Screenshot 2022-07-21 at 15 46 33" src="https://user-images.githubusercontent.com/11162307/180243359-79de5c7a-d2f0-4331-90c6-5bd2c0b5e1ac.png"> Reviewed By: cortinico Differential Revision: D38037386 Pulled By: cipolleschi fbshipit-source-id: 4db4f7c478e1afb2e4a18ba3d3f70896ed41d235
2022-07-22 15:56:02 +03:00
exit 0
fi
if [ ! -d ~/react-native ]; then
echo "No React Native checkout found. Run `checkout` first."
exit 0
fi
TARBALL_FILENAME=$(node ~/react-native/scripts/hermes/get-tarball-name.js --buildType "<< parameters.flavor >>" --releaseVersion "*")
TARBALL_PATH=$(ls $HERMES_TARBALL_ARTIFACTS_DIR/$TARBALL_FILENAME)
echo "Looking for $TARBALL_FILENAME in $HERMES_TARBALL_ARTIFACTS_DIR"
echo "$TARBALL_PATH"
if [ ! -f $TARBALL_PATH ]; then
echo "Hermes tarball not present ($TARBALL_PATH). Build Hermes from source."
Reduce flakiness of CI (#34235) Summary: How the Hermes cache worked had a concurrency issue. It used to work by asking the Hermes repository for the latest commit and using that commit as cache key to try and retrieve a built version of Hermes to avoid to compile it more than once. The problem happened when the `build_hermes_macos` was building Hermes using a commit A. While building, another PR could be merged into `hermes:main`, creating commit B. When this happened, the tasks `test_ios` and `test_ios_rntester`would try to retrieve a cached version of Hermes using commit B. That version did not exist because Hermes was created using commit A, and the job would either fail or trying to build Hermes from source, ending up taking a lot of time. This PR attaches the `.hermes-cache-key-file` to the workspace and restores it in the other jobs, making sure that the same cache key is used in all three jobs. ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://reactnative.dev/contributing/changelogs-in-pull-requests --> [General] [Changed] - Attach the `.hermes-cache-key-file` to the workspace to avoid race conditions for new PR landing on Hermes and changing the head commit between the time Hermes is built and the time it has to be consumed. Pull Request resolved: https://github.com/facebook/react-native/pull/34235 Test Plan: Tested manually, looking at the messages in CI. **build_hermes_macos** <img width="881" alt="Screenshot 2022-07-21 at 15 40 02" src="https://user-images.githubusercontent.com/11162307/180241834-776f2291-63bb-4bb2-8837-14434b50fe61.png"> **test_ios_rntester**: notice that the `echo` is not executed, meaning that the `if` does not evaluate to true and, therefore, the file has been correctly attached. <img width="956" alt="Screenshot 2022-07-21 at 15 40 52" src="https://user-images.githubusercontent.com/11162307/180242004-d9db0336-18d3-4321-a997-b538baa6beee.png"> **test_ios**: notice that the `echo` is not executed, meaning that the `if` does not evaluate to true and, therefore, the file has been correctly attached. <img width="900" alt="Screenshot 2022-07-21 at 15 46 33" src="https://user-images.githubusercontent.com/11162307/180243359-79de5c7a-d2f0-4331-90c6-5bd2c0b5e1ac.png"> Reviewed By: cortinico Differential Revision: D38037386 Pulled By: cipolleschi fbshipit-source-id: 4db4f7c478e1afb2e4a18ba3d3f70896ed41d235
2022-07-22 15:56:02 +03:00
exit 0
fi
echo "Found Hermes tarball at $TARBALL_PATH"
echo "export HERMES_ENGINE_TARBALL_PATH=$TARBALL_PATH" >> $BASH_ENV
- steps: << parameters.steps >>
- when:
condition:
equal: [ << parameters.flavor >>, "Debug"]
steps:
- save_cache:
key: *hermes_tarball_debug_cache_key
paths: *hermes_tarball_cache_paths
- when:
condition:
equal: [ << parameters.flavor >>, "Release"]
steps:
- save_cache:
key: *hermes_tarball_release_cache_key
paths: *hermes_tarball_cache_paths
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
with_hermesc_span:
description: "Makes hermesc available to the provided steps, if hermesc is present."
parameters:
flavor:
default: "Debug"
description: The Hermes build type. Must be one of "Debug", "Release".
type: enum
enum: ["Debug", "Release"]
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
steps:
type: steps
steps:
- export_hermesc:
flavor: << parameters.flavor >>
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
- steps: << parameters.steps >>
- export_hermesc:
flavor: << parameters.flavor >>
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
export_hermesc:
description: "Configures hermesc for use in Hermes builds when possible. The binary is built by either of the macOS or iOS builds, and may be cached by previous builds."
parameters:
flavor:
default: "Debug"
description: The Hermes build type. Must be one of "Debug", "Release".
type: enum
enum: ["Debug", "Release"]
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
artifacts_dir:
type: string
default: *hermes_osxbin_artifacts_dir
steps:
- run:
name: "Export path to HermesC if available"
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
command: |
# Although the hermesc binary built by debug and release jobs is
# identical, we need to store it in distinct paths as Circle CI
# cannot have two different jobs write to the same path in
# artifacts.
mkdir -p << parameters.artifacts_dir >>/Debug << parameters.artifacts_dir >>/Release
hermesc_artifacts_path=<< parameters.artifacts_dir >>/<< parameters.flavor >>/hermesc
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
hermesc_bin_path=bin/hermesc
hermes_build_dir_macos=$(pwd)/sdks/hermes/build_macosx
hermes_build_dir_ios=$(pwd)/sdks/hermes/build_iphoneos
function export_hermesc_cmake_path {
build_dir=$1
hermesc_bin=$build_dir/$hermesc_bin_path
cmake_path=$build_dir/ImportHermesc.cmake
if [[ -f $cmake_path ]]; then
echo "export HERMES_OVERRIDE_HERMESC_PATH=$cmake_path" >> $BASH_ENV
fi
if [[ ! -f $hermesc_artifacts_path ]]; then
cp $hermesc_bin $hermesc_artifacts_path
fi
}
if [[ -f $hermes_build_dir_macos/$hermesc_bin_path ]]; then
export_hermesc_cmake_path $hermes_build_dir_macos
elif [[ -f $hermes_build_dir_ios/$hermesc_bin_path ]]; then
export_hermesc_cmake_path $hermes_build_dir_ios
fi
# -------------------------
# JOBS
# -------------------------
jobs:
# -------------------------
# JOBS: Analyze PR
# -------------------------
# Analyze pull request and raise any lint/flow issues.
# Issues will be posted to the PR itself via GitHub bots.
# This workflow should only fail if the bots fail to run.
analyze_pr:
executor: reactnativeandroid
steps:
- checkout
- run_yarn
# Note: The yarn gpg key needs to be refreshed to work around https://github.com/yarnpkg/yarn/issues/7866
- run:
name: Install additional GitHub bot dependencies
# TEMP: Added workaround from https://github.com/nodesource/distributions/issues/1266#issuecomment-932583579
command: |
curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
apt update && apt install -y shellcheck jq
apt-get -y install openssl ca-certificates
update-ca-certificates
curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
apt update && apt install -y shellcheck jq
- run:
Bots cleanup, avoid leaving inline reviews when N>5 (#24923) Summary: This PR cleans up some of our GitHub bots. The overall goal is to make the contribution process just a tad nicer. ### analysis-bot * The bot will continue leaving GitHub Reviews when it finds lint issues, but will abstain from leaving inline comments if they would exceed 5 in number. * The review comment left by the bot has instructions on how to reproduce the lint issues locally. This will educate PR authors on how to run lint and fix the issues without unnecessarily spamming the PR with 50+ comments, while still providing useful reviews to authors when only a handful of lint issues slip by. * Code moved to `bots/` directory for ease of discovery and co-location with pull-bot. * Added `yarn lint-ci` command. This seems like the right choice: it's running `yarn lint` and other linters, and it is only intended to run on CI. * It's still possible to run `yarn lint-ci` locally, though the script will stop short of posting a review to GitHub unless the necessary envvars are provided. * Added `yarn shellcheck` command. This can be run locally, though it requires `shellcheck` to be installed. * Outside of this PR, I added instructions on using shellcheck to https://github.com/facebook/react-native/wiki/Development-Dependencies * Updated Circle CI config to use these new commands, and streamlined the `analyze_pr` step. * Documented analysis-bot in `bots/README.md`. ### pull-bot * Bumped `danger-js` dependency. No breaking changes found in this minor bump from what I can tell. * Documented pull-bot in `bots/README.md`. ### misc * PR template: don't use jargon. ## Changelog [Internal] [Changed] - GitHub Bots cleanup Pull Request resolved: https://github.com/facebook/react-native/pull/24923 Differential Revision: D15399744 Pulled By: hramos fbshipit-source-id: 32632e775f8554424072270e3f98542de84bfb8c
2019-05-22 05:35:40 +03:00
name: Run linters against modified files (analysis-bot)
command: GITHUB_TOKEN="$PUBLIC_ANALYSISBOT_GITHUB_TOKEN_A""$PUBLIC_ANALYSISBOT_GITHUB_TOKEN_B" yarn lint-ci
when: always
# -------------------------
# JOBS: Analyze Code
# -------------------------
analyze_code:
executor: reactnativeandroid
steps:
- checkout
- setup_artifacts
- run_yarn
- run:
name: Lint code
command: scripts/circleci/exec_swallow_error.sh yarn lint --format junit -o ./reports/junit/eslint/results.xml
when: always
- run:
name: Lint Java
command: scripts/circleci/exec_swallow_error.sh yarn lint-java --check
when: always
- run:
name: Check for errors in code using Flow (iOS)
command: yarn flow-check-ios
when: always
- run:
name: Check for errors in code using Flow (Android)
command: yarn flow-check-android
when: always
Move TypeScript declarations into react-native (#34614) Summary: ## Changelog [General] [Added] - Add `types` folder to house TypeScript types. Release TypesScript types with react-native and eventually deprecate [types/react-native](https://www.npmjs.com/package/types/react-native). The current plan is to release types/react-native for 0.70 and 0.71 while also maintaining types here. This will result in some double maintenance until 0.72 but will give community time to move off of types/react-native. After this lands, there have been changes on `main` of types that we need to update. Then, when we release 0.71 from DefinitelyTyped, we can simply copy over the `types` folder from this repo. Pull Request resolved: https://github.com/facebook/react-native/pull/34614 Test Plan: `yarn run test-typescript` for linting types * Created a new project using the TS template and my local clone of `react-native` on this branch. `npx react-native init MyTSApp --version <path-to-my-local-rn-repo> --template react-native-template-typescript` * Updated the `package.json` to remove `types/react-native` * Deleted my node_modules and re-ran yarn * Opened MyTSApp in VSCode and verified the type suggestions appeared and cmd+click to defnitions took me to the node_module dependency `react-native/types` ## Danger is failing on this PR and it's expected as it runs off the changes on `main`. [This is expected](https://docs.github.com/en/github-ae@latest/actions/using-workflows/events-that-trigger-workflows?fbclid=IwAR2_AE0Jwndt8Gu-iTQnxGxLJq7nakbi7sz8jwZ6U62JWLSdcZuvjcQ6WvE#pull_request_target). However testing it locally passes. Once merged, and these changes are on `main`, danger will pass again. ``` $ react-native/packages/react-native-bots ❯ yarn danger pr https://github.com/facebook/react-native/pull/34614 yarn run v1.22.19 $ ..react-native/node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/34614 Starting Danger PR on facebook/react-native#34614 Danger: ✓ found only warnings, not failing the build ## Warnings :lock: package.json - <i>Changes were made to package.json. This will require a manual import by a Facebook employee.</i> ✨ Done in 13.24s. ``` Reviewed By: mdvacca Differential Revision: D39479137 Pulled By: lunaleaps fbshipit-source-id: 1d506f812d566b783b6e79104cd6339b077a42a7
2022-09-19 22:26:00 +03:00
- run:
name: Run TypeScript tests
command: yarn test-typescript
when: always
- run:
name: Sanity checks
command: |
./scripts/circleci/check_license.sh
./scripts/circleci/validate_yarn_lockfile.sh
when: always
- run:
name: Check formatting
command: yarn run format-check
when: always
- store_test_results:
path: ./reports/junit
# -------------------------
# JOBS: Test JavaScript
# -------------------------
test_js:
parameters:
executor:
type: executor
default: nodelts
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
run_disabled_tests:
type: boolean
default: false
executor: << parameters.executor >>
steps:
- checkout
- setup_artifacts
- run_yarn
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
- run:
name: Install rsync
command: sudo apt update && sudo apt install rsync
# -------------------------
# Run JavaScript tests
- run:
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
name: "Run Tests: JavaScript Tests"
command: node ./scripts/run-ci-javascript-tests.js --maxWorkers 2
- run_e2e:
platform: js
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
# Optionally, run disabled tests
- when:
condition: << parameters.run_disabled_tests >>
steps:
- run: echo "Failing tests may be moved here temporarily."
# -------------------------
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
- store_test_results:
path: ./reports/junit
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
# -------------------------
# JOBS: iOS Unit Tests
# -------------------------
test_ios:
executor: reactnativeios
parameters:
use_frameworks:
type: boolean
default: false
run_unit_tests:
description: Specifies whether unit tests should run.
type: boolean
default: false
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
run_disabled_tests:
description: Specifies whether disabled tests should run. Set this to true to debug failing tests.
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
type: boolean
default: false
jsengine:
default: "Hermes"
description: Which JavaScript engine to use. Must be one of "Hermes", "JSC".
type: enum
enum: ["Hermes", "JSC"]
environment:
- REPORTS_DIR: "./reports/junit"
steps:
- checkout_code_with_cache
- setup_artifacts
- setup_ruby
- run:
name: Run Ruby Tests
command: |
cd scripts
sh run_ruby_tests.sh
- run_yarn
- *attach_hermes_workspace
- run: |
cd packages/rn-tester
bundle check || bundle install
- run:
name: Boot iPhone Simulator
command: source scripts/.tests.env && xcrun simctl boot "$IOS_DEVICE" || true
- run:
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
name: Configure Environment Variables
command: |
echo 'export PATH=/usr/local/opt/node@16/bin:$PATH' >> $BASH_ENV
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
source $BASH_ENV
- run:
name: "Brew: Tap wix/brew"
command: brew tap wix/brew >/dev/null
- brew_install:
package: applesimutils watchman
- run:
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
name: Configure Watchman
command: echo "{}" > .watchmanconfig
- when:
condition: << parameters.use_frameworks >>
steps:
- run:
name: Set USE_FRAMEWORKS=1
command: echo "export USE_FRAMEWORKS=1" >> $BASH_ENV
- run:
name: Setup the CocoaPods environment
command: bundle exec pod setup
- with_hermes_tarball_cache_span:
set_tarball_path: True
steps:
- with_rntester_pods_cache_span:
steps:
- run:
name: Generate RNTesterPods Workspace
command: |
if [[ << parameters.jsengine >> == "JSC" ]]; then
export USE_HERMES=0
fi
cd packages/rn-tester && bundle exec pod install --verbose
# -------------------------
# Runs iOS unit tests
- when:
condition: << parameters.run_unit_tests >>
steps:
- run:
name: "Run Tests: iOS Unit and Integration Tests"
command: yarn test-ios
- run:
name: Zip Derived data folder
when: always
command: |
echo "zipping tests results"
cd /Users/distiller/Library/Developer/Xcode
XCRESULT_PATH=$(find . -name '*.xcresult')
tar -zcvf xcresults.tar.gz $XCRESULT_PATH
- store_artifacts:
path: /Users/distiller/Library/Developer/Xcode/xcresults.tar.gz
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
# Optionally, run disabled tests
- when:
condition: << parameters.run_disabled_tests >>
steps:
- run: echo "Failing tests may be moved here temporarily."
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
- run:
name: "Run Tests: CocoaPods"
command: ./scripts/process-podspecs.sh
- run:
name: Free up port 8081 for iOS End-to-End Tests
command: |
# free up port 8081 for the packager before running tests
set +eo pipefail
lsof -i tcp:8081 | awk 'NR!=1 {print $2}' | xargs kill
set -eo pipefail
- run_e2e:
platform: ios
# -------------------------
# Collect Results
- report_bundle_size:
platform: ios
- store_test_results:
path: ./reports/junit
# -------------------------
# JOBS: Test Buck
# -------------------------
test_buck:
executor: reactnativeandroid
environment:
KOTLIN_HOME=third-party/kotlin
steps:
- checkout
- setup_artifacts
- run_yarn
- run:
name: Download Dependencies Using Buck
command: ./scripts/circleci/buck_fetch.sh
- run:
name: Build & Test React Native using Buck
command: |
buck build ReactAndroid/src/main/java/com/facebook/react
buck build ReactAndroid/src/main/java/com/facebook/react/shell
- run:
name: Run Tests - Android Unit Tests with Buck
command: buck test ReactAndroid/src/test/... --config build.threads=$BUILD_THREADS --xml ./reports/buck/all-results-raw.xml
- run:
name: Build JavaScript Bundle for instrumentation tests
command: node cli.js bundle --max-workers 2 --platform android --dev true --entry-file ReactAndroid/src/androidTest/js/TestBundle.js --bundle-output ReactAndroid/src/androidTest/assets/AndroidTestBundle.js
- run:
name: Build Tests - Android Instrumentation Tests with Buck
# Here, just build the instrumentation tests. There is a known issue with installing the APK to android-21+ emulator.
command: |
if [[ ! -e ReactAndroid/src/androidTest/assets/AndroidTestBundle.js ]]; then
echo "JavaScript bundle missing, cannot run instrumentation tests. Verify Build JavaScript Bundle step completed successfully."; exit 1;
fi
source scripts/android-setup.sh && NO_BUCKD=1 scripts/retry3 timeout 300 buck build ReactAndroid/src/androidTest/buck-runner:instrumentation-tests --config build.threads=$BUILD_THREADS
- run:
name: Collect Test Results
command: |
find . -type f -regex ".*/build/test-results/debug/.*xml" -exec cp {} ./reports/build/ \;
find . -type f -regex ".*/outputs/androidTest-results/connected/.*xml" -exec cp {} ./reports/outputs/ \;
find . -type f -regex ".*/buck-out/gen/ReactAndroid/src/test/.*/.*xml" -exec cp {} ./reports/buck/ \;
if [ -f ~/react-native/reports/buck/all-results-raw.xml ]; then
~/react-native/scripts/circleci/buckToJunit/buckToJunit.sh ~/react-native/reports/buck/all-results-raw.xml ~/react-native/reports/junit/results.xml
fi
when: always
- store_test_results:
path: ./reports/junit
# -------------------------
# JOBS: Test Android
# -------------------------
test_android:
executor: reactnativeandroid
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
parameters:
run_disabled_tests:
type: boolean
default: false
steps:
- checkout
- setup_artifacts
- run_yarn
# Starting emulator in advance as it takes some time to boot.
- run:
name: Create Android Virtual Device
command: source scripts/android-setup.sh && createAVD
- run:
name: Launch Android Virtual Device in Background
command: source scripts/android-setup.sh && launchAVD
background: true
- download_gradle_dependencies
- run:
name: Build & Test React Native using Gradle
command: ./gradlew buildAll
- run:
name: Build RN Tester for Release using Gradle
command: ./gradlew packages:rn-tester:android:app:assembleRelease
# Wait for AVD to finish booting before running tests
- run:
name: Wait for Android Virtual Device
command: source scripts/android-setup.sh && waitForAVD
- report_bundle_size:
platform: android
# Optionally, run disabled tests
✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392) Summary: Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`. Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job. What was done in this PR: * The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use. * The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument. * The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument * The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument ## Changelog [Internal] [CI] - ✅ Green CI, disabled test infrastructure work Pull Request resolved: https://github.com/facebook/react-native/pull/28392 Test Plan: Verified on Circle CI Reviewed By: cpojer Differential Revision: D20665512 Pulled By: hramos fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
2020-03-26 16:49:03 +03:00
- when:
condition: << parameters.run_disabled_tests >>
steps:
- run: echo "Failing tests may be moved here temporarily."
- run_e2e:
platform: android
# -------------------------
# JOBS: Test Android Template
# -------------------------
test_android_template:
executor: reactnativeandroid
parameters:
flavor:
default: "Debug"
description: The Android build type. Must be one of "Debug", "Release".
type: enum
enum: ["Debug", "Release"]
newarchitecture:
type: boolean
default: false
jsengine:
default: "Hermes"
description: Which JavaScript engine to use. Must be one of "Hermes", "JSC".
type: enum
enum: ["Hermes", "JSC"]
environment:
- PROJECT_NAME: "AndroidTemplateProject"
steps:
- checkout_code_with_cache
- run_yarn
- attach_workspace:
at: .
- when:
condition:
equal: ["JSC", << parameters.jsengine >>]
steps:
- run:
name: Set enableHermes in buld.gradle to false
command: |
node ./scripts/set-rn-engine.js -e jsc
echo "Hermes disabled."
grep enableHermes: template/android/app/build.gradle
- run:
name: Create Android template project
command: |
REPO_ROOT=$(pwd)
node ./scripts/set-rn-template-version.js "file:$REPO_ROOT/build/$(cat build/react-native-package-version)"
node cli.js init $PROJECT_NAME --directory "/tmp/$PROJECT_NAME" --template $REPO_ROOT --verbose --skip-install
cd /tmp/$PROJECT_NAME
yarn
- run:
name: Build the template application for << parameters.flavor >> with New Architecture set to << parameters.newarchitecture >>, and using the << parameters.jsengine>> JS engine.
command: |
cd /tmp/$PROJECT_NAME/android/
./gradlew assemble<< parameters.flavor >> -PnewArchEnabled=<< parameters.newarchitecture >> -PREACT_NATIVE_MAVEN_LOCAL_REPO=/root/react-native/maven-local
# -------------------------
# JOBS: Test iOS Template
# -------------------------
test_ios_template:
executor: reactnativeios
parameters:
flavor:
default: "Debug"
description: The Xcode build type. Must be one of "Debug", "Release".
type: enum
enum: ["Debug", "Release"]
architecture:
default: "OldArch"
description: Which React Native architecture to use. Must be one of "NewArch", "OldArch".
type: enum
enum: ["NewArch", "OldArch"]
jsengine:
default: "Hermes"
description: Which JavaScript engine to use. Must be one of "Hermes", "JSC".
type: enum
enum: ["Hermes", "JSC"]
flipper:
default: "WithFlipper"
description: Whether Flipper is enabled. Must be one of "WithFlipper", "WithoutFlipper".
type: enum
enum: ["WithFlipper", "WithoutFlipper"]
environment:
- PROJECT_NAME: "iOSTemplateProject"
- HERMES_WS_DIR: *hermes_workspace_root
steps:
# Early exit in case of Release and WithFlipper. The two does not make sense together.
# Unfortunately, the `exclude` parameter of `matrix` does not work, so we have to do it manually.
- when:
condition:
and:
- equal: [ << parameters.flavor >>, "Release"]
- equal: [ << parameters.flipper >>, "WithFlipper" ]
steps:
- run:
command: circleci-agent step halt # this interrupts the job successfully.
# Valid configuration, we can continue
- checkout_code_with_cache
- run_yarn
- attach_workspace:
at: .
- *attach_hermes_workspace
- when:
condition:
equal: ["Hermes", << parameters.jsengine >>]
steps:
- run:
name: Set HERMES_ENGINE_TARBALL_PATH
command: |
echo "export HERMES_ENGINE_TARBALL_PATH=$(ls -AU $HERMES_WS_DIR/hermes-runtime-darwin/hermes-runtime-darwin-*.tar.gz | head -1)" >> $BASH_ENV
- run:
name: Create iOS template project
command: |
REPO_ROOT=$(pwd)
PACKAGE=$(cat build/react-native-package-version)
PATH_TO_PACKAGE="$REPO_ROOT/build/$PACKAGE"
node ./scripts/set-rn-template-version.js "file:$PATH_TO_PACKAGE"
node cli.js init $PROJECT_NAME --directory "/tmp/$PROJECT_NAME" --template $REPO_ROOT --verbose --skip-install
- run:
name: Install iOS dependencies - Configuration << parameters.flavor >>; New Architecture << parameters.architecture >>; JS Engine << parameters.jsengine>>; Flipper << parameters.flipper >>
command: |
cd /tmp/$PROJECT_NAME
yarn install
cd ios
bundle install
if [[ << parameters.flavor >> == "Release" ]]; then
export PRODUCTION=1
fi
if [[ << parameters.architecture >> == "NewArch" ]]; then
export RCT_NEW_ARCH_ENABLED=1
fi
if [[ << parameters.jsengine >> == "JSC" ]]; then
export USE_HERMES=0
fi
if [[ << parameters.flipper >> == "WithoutFlipper" ]]; then
export NO_FLIPPER=1
fi
bundle exec pod install
- run:
name: Build template project
command: |
xcodebuild build \
-configuration << parameters.flavor >> \
-workspace /tmp/$PROJECT_NAME/ios/$PROJECT_NAME.xcworkspace \
-scheme $PROJECT_NAME \
-sdk iphonesimulator
# -------------------------
# JOBS: Test iOS RNTester
# -------------------------
test_ios_rntester:
executor: reactnativeios
parameters:
jsengine:
default: "Hermes"
description: Which JavaScript engine to use. Must be one of "Hermes", "JSC".
type: enum
enum: ["Hermes", "JSC"]
architecture:
default: "OldArch"
description: Which React Native architecture to use. Must be one of "OldArch", "NewArch".
type: enum
enum: ["NewArch", "OldArch"]
steps:
- checkout_code_with_cache
- run_yarn
- *attach_hermes_workspace
# The macOS machine can run out of storage if Hermes is enabled and built from source.
# Since this job does not use the iOS Simulator, deleting it provides a quick way to
# free up space.
- run:
name: Delete iOS Simulators
background: true
command: sudo rm -rf /Library/Developer/CoreSimulator/Profiles/Runtimes/
- with_hermes_tarball_cache_span:
set_tarball_path: True
steps:
- run:
name: Install CocoaPods dependencies - Architecture << parameters.architecture >>
command: |
rm -rf packages/rn-tester/Pods
if [[ << parameters.architecture >> == "NewArch" ]]; then
export RCT_NEW_ARCH_ENABLED=1
fi
if [[ << parameters.jsengine >> == "JSC" ]]; then
export USE_HERMES=0
fi
cd packages/rn-tester && bundle exec pod install
- run:
name: Build RNTester
command: |
xcodebuild build \
-workspace packages/rn-tester/RNTesterPods.xcworkspace \
-scheme RNTester \
-sdk iphonesimulator
# -------------------------
# JOBS: Windows
# -------------------------
test_windows:
executor:
name: win/default
parameters:
run_disabled_tests:
type: boolean
default: false
environment:
- ANDROID_HOME: "C:\\Android\\android-sdk"
- ANDROID_NDK: "C:\\Android\\android-sdk\\ndk\\20.1.5948944"
- ANDROID_BUILD_VERSION: 31
- ANDROID_TOOLS_VERSION: 31.0.0
- GRADLE_OPTS: -Dorg.gradle.daemon=false
steps:
- checkout_code_with_cache
Use Node v14 in Windows CircleCI jobs (#31656) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/31656 CircleCI's Windows executor currently ships with a pre-LTS release of Node v12, breaking our Windows jobs ([example](https://app.circleci.com/pipelines/github/facebook/react-native/9280/workflows/21e6e59c-d853-47a1-af62-1368c8ce10ce/jobs/203983)) following https://github.com/facebook/react-native/pull/30637, ultimately due to https://github.com/facebook/jest/pull/10685 dropping support for non-LTS versions in the Node v12 release line. Luckily, the Windows executor [does ship with nvm](https://github.com/circleci/circleci-docs/issues/3733) so we can use that to install a desired Node version. Rather than just pinning a later v12 release that is LTS, we pin a v14 release that is currently the most recent LTS version. NOTE: The nvm on CircleCI is https://github.com/coreybutler/nvm-windows, not https://github.com/nvm-sh/nvm, and the two aren't interchangeable. [nvm-windows has no functionality to install the latest version of a release line](https://github.com/coreybutler/nvm-windows/issues/156) so we're forced to specify an exact version, which will need to be bumped manually in the future. This isn't great, but IMO it's no worse than the current situation, where we use whichever stale version of Node happens to be bundled with the Windows CircleCI executor. Changelog: [Internal] Reviewed By: GijsWeterings Differential Revision: D28896581 fbshipit-source-id: a412376cf36054de49efa49866fe60dd964567c5
2021-06-04 17:18:34 +03:00
- run:
CircleCI: Use `nodejs-lts` for Windows tests (#34726) Summary: Currently we use `nvm install 16` in the `test_windows` CircleCI job. With the "official" non-Windows NVM, this means latest 16 (16.17.0), but that's not the case for NVM-Windows, [which simply appends `.0.0`](https://github.com/coreybutler/nvm-windows/blob/1.1.7/src/nvm.go#L384) unless [the major version is one character long](https://github.com/coreybutler/nvm-windows/blob/1.1.7/src/nvm.go#L210). The Windows orb includes NVM-Windows 1.1.7 (even on the latest 5.0.0 orb), which does not support `nvm install lts` (added 1.1.9). Updating NVM isn't trivial as the system/orb version takes precedence over any Chocolately installation. Running tests on 16.0.0 blocks Jest 29, which requires [`^16.10.0`](https://github.com/facebook/jest/blob/v29.0.3/packages/jest-create-cache-key-function/package.json#L17). I initially tried installing a specific Node JS version with NVM, but NVM-Windows 1.1.7 doesn't support newer Node versions due to https://github.com/npm/cli/issues/4234. So this PR switches from using NVM-Windows to just using Chocolately Node JS packages. `nodejs-lts` tracks the latest LTS. IMO, given we're only testing against one Node JS version with Windows, the latest LTS is a good option, but versions can be specified with `--version` if we want to pin it instead. Yarn is available through [corepack](https://nodejs.org/api/corepack.html#corepack) since 16.9, so doesn't need to be installed separately. ## Changelog [Internal] [Fixed] - CircleCI: Update Node JS version used on Windows tests from 16.0.0 to 16.17.0 Pull Request resolved: https://github.com/facebook/react-native/pull/34726 Test Plan: Tested via painful trial and error on my fork: https://app.circleci.com/pipelines/github/robhogan/react-native/19/workflows/0c23a77f-40d2-4c36-933b-53c14acb7907 Reviewed By: cipolleschi Differential Revision: D39647377 Pulled By: robhogan fbshipit-source-id: 733da49c632eab26a09ba9cd0175419b9144f9d2
2022-09-20 13:32:04 +03:00
name: Disable NVM
# Use choco to manage node versions due to https://github.com/npm/cli/issues/4234
command: nvm off
- run:
name: Install Node JS
Use Node v14 in Windows CircleCI jobs (#31656) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/31656 CircleCI's Windows executor currently ships with a pre-LTS release of Node v12, breaking our Windows jobs ([example](https://app.circleci.com/pipelines/github/facebook/react-native/9280/workflows/21e6e59c-d853-47a1-af62-1368c8ce10ce/jobs/203983)) following https://github.com/facebook/react-native/pull/30637, ultimately due to https://github.com/facebook/jest/pull/10685 dropping support for non-LTS versions in the Node v12 release line. Luckily, the Windows executor [does ship with nvm](https://github.com/circleci/circleci-docs/issues/3733) so we can use that to install a desired Node version. Rather than just pinning a later v12 release that is LTS, we pin a v14 release that is currently the most recent LTS version. NOTE: The nvm on CircleCI is https://github.com/coreybutler/nvm-windows, not https://github.com/nvm-sh/nvm, and the two aren't interchangeable. [nvm-windows has no functionality to install the latest version of a release line](https://github.com/coreybutler/nvm-windows/issues/156) so we're forced to specify an exact version, which will need to be bumped manually in the future. This isn't great, but IMO it's no worse than the current situation, where we use whichever stale version of Node happens to be bundled with the Windows CircleCI executor. Changelog: [Internal] Reviewed By: GijsWeterings Differential Revision: D28896581 fbshipit-source-id: a412376cf36054de49efa49866fe60dd964567c5
2021-06-04 17:18:34 +03:00
# Note: Version set separately for non-Windows builds, see above.
CircleCI: Use `nodejs-lts` for Windows tests (#34726) Summary: Currently we use `nvm install 16` in the `test_windows` CircleCI job. With the "official" non-Windows NVM, this means latest 16 (16.17.0), but that's not the case for NVM-Windows, [which simply appends `.0.0`](https://github.com/coreybutler/nvm-windows/blob/1.1.7/src/nvm.go#L384) unless [the major version is one character long](https://github.com/coreybutler/nvm-windows/blob/1.1.7/src/nvm.go#L210). The Windows orb includes NVM-Windows 1.1.7 (even on the latest 5.0.0 orb), which does not support `nvm install lts` (added 1.1.9). Updating NVM isn't trivial as the system/orb version takes precedence over any Chocolately installation. Running tests on 16.0.0 blocks Jest 29, which requires [`^16.10.0`](https://github.com/facebook/jest/blob/v29.0.3/packages/jest-create-cache-key-function/package.json#L17). I initially tried installing a specific Node JS version with NVM, but NVM-Windows 1.1.7 doesn't support newer Node versions due to https://github.com/npm/cli/issues/4234. So this PR switches from using NVM-Windows to just using Chocolately Node JS packages. `nodejs-lts` tracks the latest LTS. IMO, given we're only testing against one Node JS version with Windows, the latest LTS is a good option, but versions can be specified with `--version` if we want to pin it instead. Yarn is available through [corepack](https://nodejs.org/api/corepack.html#corepack) since 16.9, so doesn't need to be installed separately. ## Changelog [Internal] [Fixed] - CircleCI: Update Node JS version used on Windows tests from 16.0.0 to 16.17.0 Pull Request resolved: https://github.com/facebook/react-native/pull/34726 Test Plan: Tested via painful trial and error on my fork: https://app.circleci.com/pipelines/github/robhogan/react-native/19/workflows/0c23a77f-40d2-4c36-933b-53c14acb7907 Reviewed By: cipolleschi Differential Revision: D39647377 Pulled By: robhogan fbshipit-source-id: 733da49c632eab26a09ba9cd0175419b9144f9d2
2022-09-20 13:32:04 +03:00
command: choco install nodejs-lts
Use Node v14 in Windows CircleCI jobs (#31656) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/31656 CircleCI's Windows executor currently ships with a pre-LTS release of Node v12, breaking our Windows jobs ([example](https://app.circleci.com/pipelines/github/facebook/react-native/9280/workflows/21e6e59c-d853-47a1-af62-1368c8ce10ce/jobs/203983)) following https://github.com/facebook/react-native/pull/30637, ultimately due to https://github.com/facebook/jest/pull/10685 dropping support for non-LTS versions in the Node v12 release line. Luckily, the Windows executor [does ship with nvm](https://github.com/circleci/circleci-docs/issues/3733) so we can use that to install a desired Node version. Rather than just pinning a later v12 release that is LTS, we pin a v14 release that is currently the most recent LTS version. NOTE: The nvm on CircleCI is https://github.com/coreybutler/nvm-windows, not https://github.com/nvm-sh/nvm, and the two aren't interchangeable. [nvm-windows has no functionality to install the latest version of a release line](https://github.com/coreybutler/nvm-windows/issues/156) so we're forced to specify an exact version, which will need to be bumped manually in the future. This isn't great, but IMO it's no worse than the current situation, where we use whichever stale version of Node happens to be bundled with the Windows CircleCI executor. Changelog: [Internal] Reviewed By: GijsWeterings Differential Revision: D28896581 fbshipit-source-id: a412376cf36054de49efa49866fe60dd964567c5
2021-06-04 17:18:34 +03:00
# Setup Dependencies
- run:
CircleCI: Use `nodejs-lts` for Windows tests (#34726) Summary: Currently we use `nvm install 16` in the `test_windows` CircleCI job. With the "official" non-Windows NVM, this means latest 16 (16.17.0), but that's not the case for NVM-Windows, [which simply appends `.0.0`](https://github.com/coreybutler/nvm-windows/blob/1.1.7/src/nvm.go#L384) unless [the major version is one character long](https://github.com/coreybutler/nvm-windows/blob/1.1.7/src/nvm.go#L210). The Windows orb includes NVM-Windows 1.1.7 (even on the latest 5.0.0 orb), which does not support `nvm install lts` (added 1.1.9). Updating NVM isn't trivial as the system/orb version takes precedence over any Chocolately installation. Running tests on 16.0.0 blocks Jest 29, which requires [`^16.10.0`](https://github.com/facebook/jest/blob/v29.0.3/packages/jest-create-cache-key-function/package.json#L17). I initially tried installing a specific Node JS version with NVM, but NVM-Windows 1.1.7 doesn't support newer Node versions due to https://github.com/npm/cli/issues/4234. So this PR switches from using NVM-Windows to just using Chocolately Node JS packages. `nodejs-lts` tracks the latest LTS. IMO, given we're only testing against one Node JS version with Windows, the latest LTS is a good option, but versions can be specified with `--version` if we want to pin it instead. Yarn is available through [corepack](https://nodejs.org/api/corepack.html#corepack) since 16.9, so doesn't need to be installed separately. ## Changelog [Internal] [Fixed] - CircleCI: Update Node JS version used on Windows tests from 16.0.0 to 16.17.0 Pull Request resolved: https://github.com/facebook/react-native/pull/34726 Test Plan: Tested via painful trial and error on my fork: https://app.circleci.com/pipelines/github/robhogan/react-native/19/workflows/0c23a77f-40d2-4c36-933b-53c14acb7907 Reviewed By: cipolleschi Differential Revision: D39647377 Pulled By: robhogan fbshipit-source-id: 733da49c632eab26a09ba9cd0175419b9144f9d2
2022-09-20 13:32:04 +03:00
name: Enable Yarn with corepack
command: corepack enable
- run:
name: Display Environment info
command: npx envinfo@latest
- restore_cache:
keys:
- *windows_yarn_cache_key
- run:
name: "Yarn: Install Dependencies"
command: yarn install --frozen-lockfile --non-interactive
- save_cache:
key: *windows_yarn_cache_key
paths:
- C:\Users\circleci\AppData\Local\Yarn
# Try to install the SDK up to 3 times, since network flakiness can cause install failures
# Using a timeout of 9 mins, as circle ci will timeout if there is no output for 10 mins
- run:
name: Install Android SDK Tools
command: choco install android-sdk --timeout 540; if (!$?) { choco install android-sdk --timeout 540 --force --forcedependencies}; if (!$?) { choco install android-sdk --force --forcedependencies}
- run:
name: Setup Android SDKs
command: |
sdkmanager --licenses
sdkmanager "system-images;android-21;google_apis;armeabi-v7a"
sdkmanager "platforms;android-%ANDROID_BUILD_VERSION%"
sdkmanager "build-tools;%ANDROID_TOOLS_VERSION%"
sdkmanager "add-ons;addon-google_apis-google-23"
sdkmanager "extras;android;m2repository"
# -------------------------
# Run Tests
- run:
name: "Flow: Check Android"
command: yarn flow-check-android
- run:
name: "Flow: Check iOS"
command: yarn flow-check-ios
- run:
name: "Run Tests: JavaScript Tests"
command: yarn test
# Optionally, run disabled tests
- when:
condition: << parameters.run_disabled_tests >>
steps:
- run: echo "Failing tests may be moved here temporarily."
- run:
name: Android Build
command: ./gradlew.bat packages:rn-tester:android:app:assembleRelease
# -------------------------
# JOBS: Coverage
# -------------------------
# Collect JavaScript test coverage
js_coverage:
executor: nodelts
environment:
- CI_BRANCH: $CIRCLE_BRANCH
- CI_PULL_REQUEST: $CIRCLE_PULL_REQUEST
- CI_BUILD_NUMBER: $CIRCLE_BUILD_NUM
- CI_BUILD_URL: $CIRCLE_BUILD_URL
steps:
- checkout
- setup_artifacts
- run_yarn
- run:
name: Collect test coverage information
command: |
scripts/circleci/exec_swallow_error.sh yarn test --coverage --maxWorkers=2
if [[ -e ./coverage/lcov.info ]]; then
cat ./coverage/lcov.info | scripts/circleci/exec_swallow_error.sh ./node_modules/.bin/coveralls
fi
- store_artifacts:
path: ~/react-native/coverage/
# -------------------------
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
# JOBS: Build Hermes
# -------------------------
prepare_hermes_workspace:
docker:
- image: debian:11
environment:
- HERMES_WS_DIR: *hermes_workspace_root
- HERMES_VERSION_FILE: "sdks/.hermesversion"
steps:
- run:
name: Install dependencies
command: |
apt update
apt install -y wget git curl
curl -sL https://deb.nodesource.com/setup_16.x | bash -
apt install -y nodejs
npm install --global yarn
- checkout
- run_yarn
- run:
name: Set up Hermes workspace and caching
command: |
mkdir -p "/tmp/hermes" "/tmp/hermes/download" "/tmp/hermes/hermes"
if [ -f "$HERMES_VERSION_FILE" ]; then
cat $HERMES_VERSION_FILE > /tmp/hermes/hermesversion
else
HERMES_TAG_SHA=$(git ls-remote https://github.com/facebook/hermes main | cut -f 1 | tr -d '[:space:]')
echo $HERMES_TAG_SHA > /tmp/hermes/hermesversion
fi
cat /tmp/hermes/hermesversion
- restore_cache:
key: *hermes_workspace_cache_key
- run:
name: Download Hermes tarball
command: |
node scripts/hermes/prepare-hermes-for-build $CIRCLE_PULL_REQUEST
cp sdks/download/* $HERMES_WS_DIR/download/.
cp -r sdks/hermes/* $HERMES_WS_DIR/hermes/.
cat /tmp/hermes/hermesversion
- save_cache:
key: *hermes_workspace_cache_key
paths:
- /tmp/hermes/download/
- /tmp/hermes/hermes/
- persist_to_workspace:
root: *hermes_workspace_root
paths:
- download
- hermes
- hermesversion
build_hermesc_linux:
docker:
- image: debian:bullseye
resource_class: "xlarge"
working_directory: /root
steps:
- run:
name: Install dependencies
command: |
apt update
apt install -y git openssh-client cmake build-essential \
libreadline-dev libicu-dev zip python3
- *attach_hermes_workspace
- restore_cache:
key: *hermes_workspace_cache_key
- run:
name: Set up workspace
command: |
mkdir -p /tmp/hermes/linux64-bin
- run:
name: Build HermesC for Linux
command: |
if [ -f /tmp/hermes/linux64-bin/hermesc ]; then
echo 'Skipping; Clean "/tmp/hermes/linux64-bin" to rebuild.'
else
cd /tmp/hermes
cmake -S hermes -B build -DHERMES_STATIC_LINK=ON -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INTERPROCEDURAL_OPTIMIZATION=True -DCMAKE_CXX_FLAGS=-s -DCMAKE_C_FLAGS=-s \
-DCMAKE_EXE_LINKER_FLAGS="-Wl,--whole-archive -lpthread -Wl,--no-whole-archive"
cmake --build build --target check-hermes -j 4
cp /tmp/hermes/build/bin/hermesc /tmp/hermes/linux64-bin/.
fi
- save_cache:
key: *hermes_workspace_cache_key
paths:
- /tmp/hermes/linux64-bin/
- /tmp/hermes/hermes/destroot/
- store_artifacts:
path: /tmp/hermes/linux64-bin/
- persist_to_workspace:
root: /tmp/hermes/
paths:
- linux64-bin
build_hermes_macos:
parameters:
flavor:
default: "Debug"
description: The Hermes build type. Must be one of "Debug", "Release".
type: enum
enum: ["Debug", "Release"]
executor: reactnativeios
environment:
- HERMES_WS_DIR: *hermes_workspace_root
- HERMES_TARBALL_ARTIFACTS_DIR: *hermes_tarball_artifacts_dir
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
- HERMES_OSXBIN_ARTIFACTS_DIR: *hermes_osxbin_artifacts_dir
steps:
- checkout_code_with_cache
- run_yarn
- *attach_hermes_workspace
- when:
condition:
equal: [ << parameters.flavor >>, "Debug"]
steps:
- restore_cache:
keys:
- *hermes_workspace_debug_cache_key
- when:
condition:
equal: [ << parameters.flavor >>, "Release"]
steps:
- restore_cache:
keys:
- *hermes_workspace_release_cache_key
- run:
name: Set up workspace
command: |
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
mkdir -p $HERMES_OSXBIN_ARTIFACTS_DIR ./sdks/hermes
cp -r $HERMES_WS_DIR/hermes/* ./sdks/hermes/.
- brew_install:
package: cmake
- with_hermes_tarball_cache_span:
flavor: << parameters.flavor >>
steps:
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
- with_hermesc_span:
flavor: << parameters.flavor >>
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
steps:
- run:
name: Build the Hermes Mac frameworks
command: |
cd ./sdks/hermes || exit 1
BUILD_TYPE="<< parameters.flavor >>" ./utils/build-mac-framework.sh
- with_hermesc_span:
flavor: << parameters.flavor >>
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
steps:
- run:
name: Build the Hermes iOS frameworks
command: |
cd ./sdks/hermes || exit 1
BUILD_TYPE="<< parameters.flavor >>" ./utils/build-ios-framework.sh
- run:
name: Package the Hermes Apple frameworks
command: |
BUILD_TYPE="<< parameters.flavor >>"
echo "Packaging Hermes Apple frameworks for $BUILD_TYPE build type"
TARBALL_OUTPUT_DIR=$(mktemp -d /tmp/hermes-tarball-output-XXXXXXXX)
# get_release_version() is defined in build-apple-framework.sh
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
pushd ./sdks/hermes || exit 1
BUILD_TYPE=$BUILD_TYPE source ./utils/build-apple-framework.sh
RELEASE_VERSION=$(get_release_version)
popd
TARBALL_FILENAME=$(node ./scripts/hermes/get-tarball-name.js --buildType "$BUILD_TYPE" --releaseVersion "$RELEASE_VERSION")
echo "Packaging Hermes Apple frameworks for $BUILD_TYPE build type"
TARBALL_OUTPUT_PATH=$(node ./scripts/hermes/create-tarball.js \
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
--inputDir ./sdks/hermes \
--buildType "$BUILD_TYPE" \
--releaseVersion "$RELEASE_VERSION" \
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
--outputDir $TARBALL_OUTPUT_DIR)
echo "Hermes tarball saved to $TARBALL_OUTPUT_PATH"
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
mkdir -p $HERMES_TARBALL_ARTIFACTS_DIR
cp $TARBALL_OUTPUT_PATH $HERMES_TARBALL_ARTIFACTS_DIR/.
- when:
condition:
equal: [ << parameters.flavor >>, "Debug"]
steps:
- save_cache:
key: *hermes_workspace_debug_cache_key
paths: *hermes_workspace_macos_cache_paths
- when:
condition:
equal: [ << parameters.flavor >>, "Release"]
steps:
- save_cache:
key: *hermes_workspace_release_cache_key
paths: *hermes_workspace_macos_cache_paths
- store_artifacts:
path: *hermes_tarball_artifacts_dir
- store_artifacts:
Circle CI: Reduce build_hermes_macos Hermes SDK cache size by 75% (#34886) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/34886 ## Reduced cache size The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds. This is the `build_hermes_macos` Restore Cache step, before the changes in this diff: ``` Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE= Size: 5.2 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_host_hermesc * /Users/distiller/react-native/sdks/hermes/build_iphoneos * /Users/distiller/react-native/sdks/hermes/build_catalyst * /Users/distiller/react-native/sdks/hermes/build_iphonesimulator * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 5.2 GiB Time to restore cache: 183s This is the `build_hermes_macos` Restore Cache step, after the changes in this diff: ``` Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk= Size: 1.3 GiB Cached paths: * /Users/distiller/react-native/sdks/hermes/build_macosx * /Users/distiller/react-native/sdks/hermes/destroot Downloading cache archive... Unarchiving cache... ``` Size: 1.3 GiB Time to restore cache: 42s **This is a size reduction of 75%, and execution time reduction of 77%.** This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`. ## Added `export_hermesc` As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available: - If the cache contains hermesc, both the macOS and iOS builds will use it. - If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously. - The `export_hermesc` command will work regardless of the order of the Hermes build scripts ## Refactoring of magic strings into reusable yaml references Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D40153737 fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
2022-10-12 19:55:31 +03:00
path: *hermes_osxbin_artifacts_dir
- persist_to_workspace:
root: /tmp/hermes/
paths:
- hermes-runtime-darwin
- osx-bin
build_hermesc_windows:
executor:
name: win/default
shell: powershell.exe
environment:
- HERMES_WS_DIR: 'C:\tmp\hermes'
- ICU_URL: "https://github.com/unicode-org/icu/releases/download/release-64-2/icu4c-64_2-Win64-MSVC2017.zip"
- MSBUILD_DIR: 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin'
- CMAKE_DIR: 'C:\Program Files\CMake\bin'
steps:
- *attach_hermes_workspace
- restore_cache:
key: *hermes_windows_cache_key
- run:
name: Set up workspace
command: |
New-Item -ItemType Directory $Env:HERMES_WS_DIR
New-Item -ItemType Directory $Env:HERMES_WS_DIR\icu
New-Item -ItemType Directory $Env:HERMES_WS_DIR\deps
New-Item -ItemType Directory $Env:HERMES_WS_DIR\win64-bin
New-Item -ItemType SymbolicLink -Target tmp\hermes\hermes -Path $Env:HERMES_WS_DIR -Name hermes
- run:
name: Build HermesC for Windows
command: |
if (-not(Test-Path -Path $Env:HERMES_WS_DIR\win64-bin\hermesc.exe)) {
choco install --no-progress cmake --version 3.14.7
if (-not $?) { throw "Failed to install CMake" }
choco install --no-progress python3
if (-not $?) { throw "Failed to install Python" }
cd $Env:HERMES_WS_DIR\icu
# If Invoke-WebRequest shows a progress bar, it will fail with
# Win32 internal error "Access is denied" 0x5 occurred [...]
$progressPreference = 'silentlyContinue'
Invoke-WebRequest -Uri "$Env:ICU_URL" -OutFile "icu.zip"
Expand-Archive -Path "icu.zip" -DestinationPath "."
cd $Env:HERMES_WS_DIR
Copy-Item -Path "icu\bin64\icu*.dll" -Destination "deps"
# Include MSVC++ 2015 redistributables
Copy-Item -Path "c:\windows\system32\msvcp140.dll" -Destination "deps"
Copy-Item -Path "c:\windows\system32\vcruntime140.dll" -Destination "deps"
Copy-Item -Path "c:\windows\system32\vcruntime140_1.dll" -Destination "deps"
$Env:PATH += ";$Env:CMAKE_DIR;$Env:MSBUILD_DIR"
$Env:ICU_ROOT = "$Env:HERMES_WS_DIR\icu"
cmake -S hermes -B build_release -G 'Visual Studio 16 2019' -Ax64 -DCMAKE_BUILD_TYPE=Release -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=True -DHERMES_ENABLE_WIN10_ICU_FALLBACK=OFF
if (-not $?) { throw "Failed to configure Hermes" }
cd build_release
cmake --build . --target hermesc --config Release
if (-not $?) { throw "Failed to build Hermes" }
cd $Env:HERMES_WS_DIR
Copy-Item -Path "build_release\bin\Release\hermesc.exe" -Destination "win64-bin"
# Include Windows runtime dependencies
Copy-Item -Path "deps\*" -Destination "win64-bin"
}
else {
Write-Host "Skipping; Clean c:\tmp\hermes\win64-bin to rebuild."
}
- save_cache:
key: *hermes_windows_cache_key
paths:
- C:\tmp\hermes\win64-bin\
- C:\tmp\hermes\hermes\icu\
- C:\tmp\hermes\hermes\deps\
- C:\tmp\hermes\hermes\build_release\
- store_artifacts:
path: C:\tmp\hermes\win64-bin\
- persist_to_workspace:
root: C:\tmp\hermes\
paths:
- win64-bin
# -------------------------
# JOBS: Releases
# -------------------------
prepare_package_for_release:
Use CircleCI API to trigger releases (#32937) Summary: Changelog: [Internal] * Refactor release automation so it doesn't use intermediate tags to trigger the release workflow. Now, we POST to CircleCI's ["trigger pipeline" API](https://circleci.com/docs/api/v2/#operation/triggerPipeline) * This does have the con of needing to give CircleCI project permission for whoever wants to run a release as you'll need a token to trigger * See related discussion: https://github.com/reactwg/react-native-releases/discussions/7#discussioncomment-1836420 Description of changes: * Changes to config.yml allow us to use our POST data to trigger a certain workflow. There is no direct API to trigger a workflow, CircleCI only has an API to trigger pipelines, so the suggestion is to leverage conditionals: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2 * Update `bump-oss-version` to make the api call -- the instructions for running a release are still the same: https://github.com/facebook/react-native/wiki/Release-Process#creating-0minor0-rc0 * Would be good to make this a yarn script as tido64 mentioned * Remove unused utilities now that we don't use intermediate tags like `publish-...` Pull Request resolved: https://github.com/facebook/react-native/pull/32937 Test Plan: Have this on a Github branch and tried this out locally: ## Running release script Running the bump-oss script (I had to hack it locally to be allowed to run on a non-release branch): {F694804729} * Link to resulting workflow: https://app.circleci.com/pipelines/github/facebook/react-native/11836 -- you can [verify that the parameters are the same as I passed](https://app.circleci.com/pipelines/github/facebook/react-native/11836/workflows/59ac0c86-5fe3-4d7a-80e9-c61129d49e9f/jobs/232388?invite=true#step-106-2) ## Other attempts triggering this workflow Notice that when I tried to run it on an actual release-branch (0.67-stable) but because the `config.yml` changes aren't on that branch, the job faisl | {F694804321} | ## Verifying the right workflows trigger on a regular push * Notice that the workflows "analysis" and "test" are still triggered on push (ie, the `unless:` clause isn't messing things up) {F694804320} Reviewed By: sota000 Differential Revision: D33715336 Pulled By: lunaleaps fbshipit-source-id: 82672d6d50768015bdfc9f4ea4d22aa801b84f06
2022-01-25 01:06:49 +03:00
parameters:
version:
type: string
latest:
type: boolean
default: false
dryrun:
type: boolean
default: false
executor: reactnativeios
steps:
- checkout_code_with_cache
- run_yarn
- add_ssh_keys:
fingerprints:
- "1c:98:e0:3a:52:79:95:29:12:cd:b4:87:5b:41:e2:bb"
- brew_install:
package: cmake
- run:
name: "Set new react-native version and commit changes"
command: |
node ./scripts/prepare-package-for-release.js -v << parameters.version >> -l << parameters.latest >> --dry-run << parameters.dryrun >>
build_npm_package:
parameters:
release_type:
description: The type of release to build. Must be one of "nightly", "release", "dry-run".
type: enum
enum: ["nightly", "release", "dry-run"]
default: "dry-run"
executor: reactnativeandroid
environment:
- HERMES_WS_DIR: *hermes_workspace_root
steps:
Seed ssh known hosts with github's public key (#28370) Summary: The [previous attempt](https://github.com/facebook/react-native/pull/28304) to fix the publish step failed, so now reverting to manually configuring things. This PR adds an entry to SSH’s `known_hosts` file using github.com’s public key that I have verified as per [these instructions](https://serverfault.com/a/807363): ``` ~/C/R/react-native [master] » nmap github.com --script ssh-hostkey Nmap scan report for github.com (140.82.118.4) rDNS record for 140.82.118.4: lb-140-82-118-4-ams.github.com PORT STATE SERVICE 22/tcp open ssh | ssh-hostkey: | 1024 ad:1c:08:a4:40:e3:6f:9c:f5:66:26:5d:4b:33:5d:8c (DSA) |_ 2048 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48 (RSA) ``` These fingerprints line up with [the ones posted by GitHub](https://help.github.com/en/github/authenticating-to-github/githubs-ssh-key-fingerprints), so my setup should be good and can be trusted to grab the public key from the right host: ``` ~/C/R/react-native [master] » ssh-keyscan -t rsa -H github.com # github.com:22 SSH-2.0-babeld-d48c3acd |1|If6MU203eXTaaWL678YEfWkVMrw=|kqLeIAyTy8pzpj8x8Ae4Fr8Mtlc= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ== ``` ## Changelog [Internal] [Fixed] - Make automated publishing of packages from CI work again Pull Request resolved: https://github.com/facebook/react-native/pull/28370 Test Plan: I used the command being added in this PR in [a failed CI job](https://app.circleci.com/pipelines/github/facebook/react-native/4104/workflows/916127cb-177f-4583-9f90-cae5318041d8/jobs/140810). When I invoked the publish script manually I was not greeted by the blocking prompt and the package was successfully published: https://www.npmjs.com/package/react-native/v/0.0.0-56cf99a96 Reviewed By: cpojer Differential Revision: D20601527 Pulled By: hramos fbshipit-source-id: b1a4405228408cfc4a1b3b44ab88c79522af3a66
2020-03-24 21:04:57 +03:00
- run:
name: Add github.com to SSH known hosts
command: |
mkdir -p ~/.ssh
echo '|1|If6MU203eXTaaWL678YEfWkVMrw=|kqLeIAyTy8pzpj8x8Ae4Fr8Mtlc= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==' >> ~/.ssh/known_hosts
- checkout
- *attach_hermes_workspace
- run:
name: Copy Hermes binaries
command: |
mkdir -p ./sdks/hermesc ./sdks/hermesc/osx-bin ./sdks/hermesc/win64-bin ./sdks/hermesc/linux64-bin
# When build_hermes_macos runs as a matrix, it outputs
if [[ -d $HERMES_WS_DIR/osx-bin/Release ]]; then
cp -r $HERMES_WS_DIR/osx-bin/Release/* ./sdks/hermesc/osx-bin/.
elif [[ -d $HERMES_WS_DIR/osx-bin/Debug ]]; then
cp -r $HERMES_WS_DIR/osx-bin/Debug/* ./sdks/hermesc/osx-bin/.
else
ls $HERMES_WS_DIR/osx-bin || echo "hermesc macOS artifacts directory missing."
echo "Could not locate macOS hermesc binary."; exit 1;
fi
cp -r $HERMES_WS_DIR/win64-bin/* ./sdks/hermesc/win64-bin/.
cp -r $HERMES_WS_DIR/linux64-bin/* ./sdks/hermesc/linux64-bin/.
mkdir -p ./ReactAndroid/external-artifacts/artifacts/
cp $HERMES_WS_DIR/hermes-runtime-darwin/hermes-runtime-darwin-debug-*.tar.gz ./ReactAndroid/external-artifacts/artifacts/hermes-ios-debug.tar.gz
cp $HERMES_WS_DIR/hermes-runtime-darwin/hermes-runtime-darwin-release-*.tar.gz ./ReactAndroid/external-artifacts/artifacts/hermes-ios-release.tar.gz
- run_yarn
- download_gradle_dependencies
# START: Stables and nightlies
# This conditional step sets up the necessary credentials for publishing react-native to npm,
# and for interacting with GitHub as the react-native-bot account. Important: these steps
# should not be allowed to run on commits from pull requests.
- when:
condition:
or:
- equal: [ "release", << parameters.release_type >> ]
- equal: [ "nightly", << parameters.release_type >> ]
steps:
- run: echo "//registry.npmjs.org/:_authToken=${CIRCLE_NPM_TOKEN}" > ~/.npmrc
- run: |
git config --global user.email "react-native-bot@users.noreply.github.com"
git config --global user.name "npm Deployment Script"
echo "machine github.com login react-native-bot password $GITHUB_TOKEN" > ~/.netrc
# END: Stables and nightlies
- run: node ./scripts/publish-npm.js --<< parameters.release_type >>
- run:
name: Zip Hermes Native Symbols
command: zip -r /tmp/hermes-native-symbols.zip ~/react-native/ReactAndroid/hermes-engine/build/intermediates/cmake/
- store_artifacts:
path: /tmp/hermes-native-symbols.zip
- run:
name: Zip Maven Artifacts from /tmp/maven-local
command: zip -r /tmp/maven-local.zip /tmp/maven-local
- store_artifacts:
path: /tmp/maven-local.zip
- persist_to_workspace:
root: /tmp
paths:
- maven-local
# START: Commitlies
# Provide a react-native package for this commit as a Circle CI release artifact.
- when:
condition:
equal: [ "dry-run", << parameters.release_type >> ]
steps:
- run:
name: Build release package as a job artifact
command: |
mkdir -p build
FILENAME=$(npm pack)
mv $FILENAME build/
echo $FILENAME > build/react-native-package-version
- store_artifacts:
path: ~/react-native/build/
destination: build
- persist_to_workspace:
root: .
paths:
- build/*
# END: Commitlies
# START: Commits from pull requests
# When building commits from pull requests, leave a comment on the PR with a link to build artifacts
- when:
condition:
matches: { pattern: '^pull\/.*$', value: << pipeline.git.branch >> }
steps:
- run:
name: Post link to PR build artifacts (pull-bot)
command: GITHUB_TOKEN="$PUBLIC_PULLBOT_GITHUB_TOKEN_A""$PUBLIC_PULLBOT_GITHUB_TOKEN_B" scripts/circleci/post-artifacts-link.sh || true
# END: Commits from pull requests
# START: Stable releases
- when:
condition:
equal: [ "release", << parameters.release_type >> ]
steps:
- run:
name: Update rn-diff-purge to generate upgrade-support diff
command: |
curl -X POST https://api.github.com/repos/react-native-community/rn-diff-purge/dispatches \
-H "Accept: application/vnd.github.v3+json" \
-u "$PAT_USERNAME:$PAT_TOKEN" \
-d "{\"event_type\": \"publish\", \"client_payload\": { \"version\": \"${CIRCLE_TAG:1}\" }}"
# END: Stable releases
# START: Stables and commitlies
- when:
condition:
or:
- equal: [ "release", << parameters.release_type >> ]
- equal: [ "dry-run", << parameters.release_type >> ]
steps:
- run:
name: Install dependencies
command: apt update && apt install -y jq jo
- run:
name: Create draft GitHub Release and upload Hermes binaries
command: |
RELEASE_VERSION=$(cat build/.version)
if [[ << parameters.release_type >> == "release" ]]; then
GIT_TAG=$CIRCLE_TAG
elif [[ << parameters.release_type >> == "dry-run" ]]; then
GIT_TAG=v1000.0.0
fi
ARTIFACTS=("")
for build_type in "Debug" "Release"; do
TARBALL_FILENAME=$(node ./scripts/hermes/get-tarball-name.js \
--buildType $build_type \
--releaseVersion $RELEASE_VERSION)
ARTIFACTS+=("$HERMES_WS_DIR/hermes-runtime-darwin/$TARBALL_FILENAME")
done
./scripts/circleci/create_github_release.sh \
<< parameters.release_type >> \
$GIT_TAG \
$RELEASE_VERSION \
$GITHUB_TOKEN \
"${ARTIFACTS[@]}"
# END: Stable and commitlies
# -------------------------
# JOBS: Nightly
# -------------------------
nightly_job:
machine:
image: ubuntu-2004:202010-01
steps:
- run:
name: Nightly
command: |
echo "Nightly build run"
Use CircleCI API to trigger releases (#32937) Summary: Changelog: [Internal] * Refactor release automation so it doesn't use intermediate tags to trigger the release workflow. Now, we POST to CircleCI's ["trigger pipeline" API](https://circleci.com/docs/api/v2/#operation/triggerPipeline) * This does have the con of needing to give CircleCI project permission for whoever wants to run a release as you'll need a token to trigger * See related discussion: https://github.com/reactwg/react-native-releases/discussions/7#discussioncomment-1836420 Description of changes: * Changes to config.yml allow us to use our POST data to trigger a certain workflow. There is no direct API to trigger a workflow, CircleCI only has an API to trigger pipelines, so the suggestion is to leverage conditionals: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2 * Update `bump-oss-version` to make the api call -- the instructions for running a release are still the same: https://github.com/facebook/react-native/wiki/Release-Process#creating-0minor0-rc0 * Would be good to make this a yarn script as tido64 mentioned * Remove unused utilities now that we don't use intermediate tags like `publish-...` Pull Request resolved: https://github.com/facebook/react-native/pull/32937 Test Plan: Have this on a Github branch and tried this out locally: ## Running release script Running the bump-oss script (I had to hack it locally to be allowed to run on a non-release branch): {F694804729} * Link to resulting workflow: https://app.circleci.com/pipelines/github/facebook/react-native/11836 -- you can [verify that the parameters are the same as I passed](https://app.circleci.com/pipelines/github/facebook/react-native/11836/workflows/59ac0c86-5fe3-4d7a-80e9-c61129d49e9f/jobs/232388?invite=true#step-106-2) ## Other attempts triggering this workflow Notice that when I tried to run it on an actual release-branch (0.67-stable) but because the `config.yml` changes aren't on that branch, the job faisl | {F694804321} | ## Verifying the right workflows trigger on a regular push * Notice that the workflows "analysis" and "test" are still triggered on push (ie, the `unless:` clause isn't messing things up) {F694804320} Reviewed By: sota000 Differential Revision: D33715336 Pulled By: lunaleaps fbshipit-source-id: 82672d6d50768015bdfc9f4ea4d22aa801b84f06
2022-01-25 01:06:49 +03:00
# -------------------------
# PIPELINE PARAMETERS
# -------------------------
parameters:
run_package_release_workflow_only:
default: false
type: boolean
release_latest:
default: false
type: boolean
release_version:
default: "9999"
type: string
# -------------------------
# WORK FLOWS
Use CircleCI API to trigger releases (#32937) Summary: Changelog: [Internal] * Refactor release automation so it doesn't use intermediate tags to trigger the release workflow. Now, we POST to CircleCI's ["trigger pipeline" API](https://circleci.com/docs/api/v2/#operation/triggerPipeline) * This does have the con of needing to give CircleCI project permission for whoever wants to run a release as you'll need a token to trigger * See related discussion: https://github.com/reactwg/react-native-releases/discussions/7#discussioncomment-1836420 Description of changes: * Changes to config.yml allow us to use our POST data to trigger a certain workflow. There is no direct API to trigger a workflow, CircleCI only has an API to trigger pipelines, so the suggestion is to leverage conditionals: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2 * Update `bump-oss-version` to make the api call -- the instructions for running a release are still the same: https://github.com/facebook/react-native/wiki/Release-Process#creating-0minor0-rc0 * Would be good to make this a yarn script as tido64 mentioned * Remove unused utilities now that we don't use intermediate tags like `publish-...` Pull Request resolved: https://github.com/facebook/react-native/pull/32937 Test Plan: Have this on a Github branch and tried this out locally: ## Running release script Running the bump-oss script (I had to hack it locally to be allowed to run on a non-release branch): {F694804729} * Link to resulting workflow: https://app.circleci.com/pipelines/github/facebook/react-native/11836 -- you can [verify that the parameters are the same as I passed](https://app.circleci.com/pipelines/github/facebook/react-native/11836/workflows/59ac0c86-5fe3-4d7a-80e9-c61129d49e9f/jobs/232388?invite=true#step-106-2) ## Other attempts triggering this workflow Notice that when I tried to run it on an actual release-branch (0.67-stable) but because the `config.yml` changes aren't on that branch, the job faisl | {F694804321} | ## Verifying the right workflows trigger on a regular push * Notice that the workflows "analysis" and "test" are still triggered on push (ie, the `unless:` clause isn't messing things up) {F694804320} Reviewed By: sota000 Differential Revision: D33715336 Pulled By: lunaleaps fbshipit-source-id: 82672d6d50768015bdfc9f4ea4d22aa801b84f06
2022-01-25 01:06:49 +03:00
#
# When creating a new workflow, make sure to include condition `unless: << pipeline.parameters.run_package_release_workflow_only >>`
# It's setup this way so we can trigger a release via a POST
# See limitations: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2
# -------------------------
workflows:
version: 2
tests:
Use CircleCI API to trigger releases (#32937) Summary: Changelog: [Internal] * Refactor release automation so it doesn't use intermediate tags to trigger the release workflow. Now, we POST to CircleCI's ["trigger pipeline" API](https://circleci.com/docs/api/v2/#operation/triggerPipeline) * This does have the con of needing to give CircleCI project permission for whoever wants to run a release as you'll need a token to trigger * See related discussion: https://github.com/reactwg/react-native-releases/discussions/7#discussioncomment-1836420 Description of changes: * Changes to config.yml allow us to use our POST data to trigger a certain workflow. There is no direct API to trigger a workflow, CircleCI only has an API to trigger pipelines, so the suggestion is to leverage conditionals: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2 * Update `bump-oss-version` to make the api call -- the instructions for running a release are still the same: https://github.com/facebook/react-native/wiki/Release-Process#creating-0minor0-rc0 * Would be good to make this a yarn script as tido64 mentioned * Remove unused utilities now that we don't use intermediate tags like `publish-...` Pull Request resolved: https://github.com/facebook/react-native/pull/32937 Test Plan: Have this on a Github branch and tried this out locally: ## Running release script Running the bump-oss script (I had to hack it locally to be allowed to run on a non-release branch): {F694804729} * Link to resulting workflow: https://app.circleci.com/pipelines/github/facebook/react-native/11836 -- you can [verify that the parameters are the same as I passed](https://app.circleci.com/pipelines/github/facebook/react-native/11836/workflows/59ac0c86-5fe3-4d7a-80e9-c61129d49e9f/jobs/232388?invite=true#step-106-2) ## Other attempts triggering this workflow Notice that when I tried to run it on an actual release-branch (0.67-stable) but because the `config.yml` changes aren't on that branch, the job faisl | {F694804321} | ## Verifying the right workflows trigger on a regular push * Notice that the workflows "analysis" and "test" are still triggered on push (ie, the `unless:` clause isn't messing things up) {F694804320} Reviewed By: sota000 Differential Revision: D33715336 Pulled By: lunaleaps fbshipit-source-id: 82672d6d50768015bdfc9f4ea4d22aa801b84f06
2022-01-25 01:06:49 +03:00
unless: << pipeline.parameters.run_package_release_workflow_only >>
jobs:
- prepare_hermes_workspace
- build_hermesc_linux:
requires:
- prepare_hermes_workspace
- build_hermes_macos:
requires:
- prepare_hermes_workspace
matrix:
parameters:
flavor: ["Debug", "Release"]
- build_hermesc_windows:
requires:
- prepare_hermes_workspace
- build_npm_package:
# Build a release package on every untagged commit, but do not publish to npm.
release_type: "dry-run"
requires:
- build_hermesc_linux
- build_hermes_macos
- build_hermesc_windows
- test_js:
run_disabled_tests: false
- test_android:
run_disabled_tests: false
- test_android_template:
requires:
- build_npm_package
matrix:
parameters:
newarchitecture: [true, false]
jsengine: ["Hermes", "JSC"]
flavor: ["Debug", "Release"]
- test_buck
- test_ios_template:
requires:
- build_npm_package
matrix:
parameters:
architecture: ["NewArch", "OldArch"]
flavor: ["Debug", "Release"]
jsengine: ["Hermes", "JSC"]
flipper: ["WithFlipper", "WithoutFlipper"]
- test_ios_rntester:
requires:
- build_hermes_macos
matrix:
parameters:
architecture: ["NewArch", "OldArch"]
jsengine: ["Hermes", "JSC"]
- test_ios:
run_unit_tests: true
requires:
- build_hermes_macos
matrix:
parameters:
jsengine: ["Hermes", "JSC"]
# DISABLED: USE_FRAMEWORKS=1 not supported by Flipper
# - test_ios:
# name: test_ios_frameworks
# use_frameworks: true
# run_unit_tests: true
# requires:
# - build_ios_frameworks
- test_js:
name: test_js_prev_lts
executor: nodeprevlts
- test_windows:
run_disabled_tests: false
Use CircleCI API to trigger releases (#32937) Summary: Changelog: [Internal] * Refactor release automation so it doesn't use intermediate tags to trigger the release workflow. Now, we POST to CircleCI's ["trigger pipeline" API](https://circleci.com/docs/api/v2/#operation/triggerPipeline) * This does have the con of needing to give CircleCI project permission for whoever wants to run a release as you'll need a token to trigger * See related discussion: https://github.com/reactwg/react-native-releases/discussions/7#discussioncomment-1836420 Description of changes: * Changes to config.yml allow us to use our POST data to trigger a certain workflow. There is no direct API to trigger a workflow, CircleCI only has an API to trigger pipelines, so the suggestion is to leverage conditionals: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2 * Update `bump-oss-version` to make the api call -- the instructions for running a release are still the same: https://github.com/facebook/react-native/wiki/Release-Process#creating-0minor0-rc0 * Would be good to make this a yarn script as tido64 mentioned * Remove unused utilities now that we don't use intermediate tags like `publish-...` Pull Request resolved: https://github.com/facebook/react-native/pull/32937 Test Plan: Have this on a Github branch and tried this out locally: ## Running release script Running the bump-oss script (I had to hack it locally to be allowed to run on a non-release branch): {F694804729} * Link to resulting workflow: https://app.circleci.com/pipelines/github/facebook/react-native/11836 -- you can [verify that the parameters are the same as I passed](https://app.circleci.com/pipelines/github/facebook/react-native/11836/workflows/59ac0c86-5fe3-4d7a-80e9-c61129d49e9f/jobs/232388?invite=true#step-106-2) ## Other attempts triggering this workflow Notice that when I tried to run it on an actual release-branch (0.67-stable) but because the `config.yml` changes aren't on that branch, the job faisl | {F694804321} | ## Verifying the right workflows trigger on a regular push * Notice that the workflows "analysis" and "test" are still triggered on push (ie, the `unless:` clause isn't messing things up) {F694804320} Reviewed By: sota000 Differential Revision: D33715336 Pulled By: lunaleaps fbshipit-source-id: 82672d6d50768015bdfc9f4ea4d22aa801b84f06
2022-01-25 01:06:49 +03:00
# This workflow should only be triggered by release script
package_release:
when: << pipeline.parameters.run_package_release_workflow_only >>
jobs:
Use CircleCI API to trigger releases (#32937) Summary: Changelog: [Internal] * Refactor release automation so it doesn't use intermediate tags to trigger the release workflow. Now, we POST to CircleCI's ["trigger pipeline" API](https://circleci.com/docs/api/v2/#operation/triggerPipeline) * This does have the con of needing to give CircleCI project permission for whoever wants to run a release as you'll need a token to trigger * See related discussion: https://github.com/reactwg/react-native-releases/discussions/7#discussioncomment-1836420 Description of changes: * Changes to config.yml allow us to use our POST data to trigger a certain workflow. There is no direct API to trigger a workflow, CircleCI only has an API to trigger pipelines, so the suggestion is to leverage conditionals: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2 * Update `bump-oss-version` to make the api call -- the instructions for running a release are still the same: https://github.com/facebook/react-native/wiki/Release-Process#creating-0minor0-rc0 * Would be good to make this a yarn script as tido64 mentioned * Remove unused utilities now that we don't use intermediate tags like `publish-...` Pull Request resolved: https://github.com/facebook/react-native/pull/32937 Test Plan: Have this on a Github branch and tried this out locally: ## Running release script Running the bump-oss script (I had to hack it locally to be allowed to run on a non-release branch): {F694804729} * Link to resulting workflow: https://app.circleci.com/pipelines/github/facebook/react-native/11836 -- you can [verify that the parameters are the same as I passed](https://app.circleci.com/pipelines/github/facebook/react-native/11836/workflows/59ac0c86-5fe3-4d7a-80e9-c61129d49e9f/jobs/232388?invite=true#step-106-2) ## Other attempts triggering this workflow Notice that when I tried to run it on an actual release-branch (0.67-stable) but because the `config.yml` changes aren't on that branch, the job faisl | {F694804321} | ## Verifying the right workflows trigger on a regular push * Notice that the workflows "analysis" and "test" are still triggered on push (ie, the `unless:` clause isn't messing things up) {F694804320} Reviewed By: sota000 Differential Revision: D33715336 Pulled By: lunaleaps fbshipit-source-id: 82672d6d50768015bdfc9f4ea4d22aa801b84f06
2022-01-25 01:06:49 +03:00
# This job will trigger publish_release workflow
- prepare_package_for_release:
name: prepare_package_for_release
Use CircleCI API to trigger releases (#32937) Summary: Changelog: [Internal] * Refactor release automation so it doesn't use intermediate tags to trigger the release workflow. Now, we POST to CircleCI's ["trigger pipeline" API](https://circleci.com/docs/api/v2/#operation/triggerPipeline) * This does have the con of needing to give CircleCI project permission for whoever wants to run a release as you'll need a token to trigger * See related discussion: https://github.com/reactwg/react-native-releases/discussions/7#discussioncomment-1836420 Description of changes: * Changes to config.yml allow us to use our POST data to trigger a certain workflow. There is no direct API to trigger a workflow, CircleCI only has an API to trigger pipelines, so the suggestion is to leverage conditionals: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2 * Update `bump-oss-version` to make the api call -- the instructions for running a release are still the same: https://github.com/facebook/react-native/wiki/Release-Process#creating-0minor0-rc0 * Would be good to make this a yarn script as tido64 mentioned * Remove unused utilities now that we don't use intermediate tags like `publish-...` Pull Request resolved: https://github.com/facebook/react-native/pull/32937 Test Plan: Have this on a Github branch and tried this out locally: ## Running release script Running the bump-oss script (I had to hack it locally to be allowed to run on a non-release branch): {F694804729} * Link to resulting workflow: https://app.circleci.com/pipelines/github/facebook/react-native/11836 -- you can [verify that the parameters are the same as I passed](https://app.circleci.com/pipelines/github/facebook/react-native/11836/workflows/59ac0c86-5fe3-4d7a-80e9-c61129d49e9f/jobs/232388?invite=true#step-106-2) ## Other attempts triggering this workflow Notice that when I tried to run it on an actual release-branch (0.67-stable) but because the `config.yml` changes aren't on that branch, the job faisl | {F694804321} | ## Verifying the right workflows trigger on a regular push * Notice that the workflows "analysis" and "test" are still triggered on push (ie, the `unless:` clause isn't messing things up) {F694804320} Reviewed By: sota000 Differential Revision: D33715336 Pulled By: lunaleaps fbshipit-source-id: 82672d6d50768015bdfc9f4ea4d22aa801b84f06
2022-01-25 01:06:49 +03:00
version: << pipeline.parameters.release_version >>
latest : << pipeline.parameters.release_latest >>
Use CircleCI API to trigger releases (#32937) Summary: Changelog: [Internal] * Refactor release automation so it doesn't use intermediate tags to trigger the release workflow. Now, we POST to CircleCI's ["trigger pipeline" API](https://circleci.com/docs/api/v2/#operation/triggerPipeline) * This does have the con of needing to give CircleCI project permission for whoever wants to run a release as you'll need a token to trigger * See related discussion: https://github.com/reactwg/react-native-releases/discussions/7#discussioncomment-1836420 Description of changes: * Changes to config.yml allow us to use our POST data to trigger a certain workflow. There is no direct API to trigger a workflow, CircleCI only has an API to trigger pipelines, so the suggestion is to leverage conditionals: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2 * Update `bump-oss-version` to make the api call -- the instructions for running a release are still the same: https://github.com/facebook/react-native/wiki/Release-Process#creating-0minor0-rc0 * Would be good to make this a yarn script as tido64 mentioned * Remove unused utilities now that we don't use intermediate tags like `publish-...` Pull Request resolved: https://github.com/facebook/react-native/pull/32937 Test Plan: Have this on a Github branch and tried this out locally: ## Running release script Running the bump-oss script (I had to hack it locally to be allowed to run on a non-release branch): {F694804729} * Link to resulting workflow: https://app.circleci.com/pipelines/github/facebook/react-native/11836 -- you can [verify that the parameters are the same as I passed](https://app.circleci.com/pipelines/github/facebook/react-native/11836/workflows/59ac0c86-5fe3-4d7a-80e9-c61129d49e9f/jobs/232388?invite=true#step-106-2) ## Other attempts triggering this workflow Notice that when I tried to run it on an actual release-branch (0.67-stable) but because the `config.yml` changes aren't on that branch, the job faisl | {F694804321} | ## Verifying the right workflows trigger on a regular push * Notice that the workflows "analysis" and "test" are still triggered on push (ie, the `unless:` clause isn't messing things up) {F694804320} Reviewed By: sota000 Differential Revision: D33715336 Pulled By: lunaleaps fbshipit-source-id: 82672d6d50768015bdfc9f4ea4d22aa801b84f06
2022-01-25 01:06:49 +03:00
publish_release:
unless: << pipeline.parameters.run_package_release_workflow_only >>
jobs:
- prepare_hermes_workspace:
filters: *only_release_tags
- build_hermesc_linux:
filters: *only_release_tags
requires:
- prepare_hermes_workspace
- build_hermes_macos:
filters: *only_release_tags
requires:
- prepare_hermes_workspace
matrix:
parameters:
flavor: ["Debug", "Release"]
- build_hermesc_windows:
filters: *only_release_tags
requires:
- prepare_hermes_workspace
Use CircleCI API to trigger releases (#32937) Summary: Changelog: [Internal] * Refactor release automation so it doesn't use intermediate tags to trigger the release workflow. Now, we POST to CircleCI's ["trigger pipeline" API](https://circleci.com/docs/api/v2/#operation/triggerPipeline) * This does have the con of needing to give CircleCI project permission for whoever wants to run a release as you'll need a token to trigger * See related discussion: https://github.com/reactwg/react-native-releases/discussions/7#discussioncomment-1836420 Description of changes: * Changes to config.yml allow us to use our POST data to trigger a certain workflow. There is no direct API to trigger a workflow, CircleCI only has an API to trigger pipelines, so the suggestion is to leverage conditionals: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2 * Update `bump-oss-version` to make the api call -- the instructions for running a release are still the same: https://github.com/facebook/react-native/wiki/Release-Process#creating-0minor0-rc0 * Would be good to make this a yarn script as tido64 mentioned * Remove unused utilities now that we don't use intermediate tags like `publish-...` Pull Request resolved: https://github.com/facebook/react-native/pull/32937 Test Plan: Have this on a Github branch and tried this out locally: ## Running release script Running the bump-oss script (I had to hack it locally to be allowed to run on a non-release branch): {F694804729} * Link to resulting workflow: https://app.circleci.com/pipelines/github/facebook/react-native/11836 -- you can [verify that the parameters are the same as I passed](https://app.circleci.com/pipelines/github/facebook/react-native/11836/workflows/59ac0c86-5fe3-4d7a-80e9-c61129d49e9f/jobs/232388?invite=true#step-106-2) ## Other attempts triggering this workflow Notice that when I tried to run it on an actual release-branch (0.67-stable) but because the `config.yml` changes aren't on that branch, the job faisl | {F694804321} | ## Verifying the right workflows trigger on a regular push * Notice that the workflows "analysis" and "test" are still triggered on push (ie, the `unless:` clause isn't messing things up) {F694804320} Reviewed By: sota000 Differential Revision: D33715336 Pulled By: lunaleaps fbshipit-source-id: 82672d6d50768015bdfc9f4ea4d22aa801b84f06
2022-01-25 01:06:49 +03:00
# This job will trigger when a version tag is pushed (by package_release)
- build_npm_package:
name: build_and_publish_npm_package
context: react-native-bot
release_type: "release"
filters: *only_release_tags
requires:
- build_hermesc_linux
- build_hermes_macos
- build_hermesc_windows
package_and_publish_release_dryrun:
jobs:
- prepare_package_for_release:
name: prepare_package_for_release
version: 'v1000.0.1'
latest : false
dryrun: true
- prepare_hermes_workspace:
requires:
- prepare_package_for_release
- build_hermesc_linux:
requires:
- prepare_hermes_workspace
- build_hermes_macos:
requires:
- prepare_hermes_workspace
matrix:
parameters:
flavor: ["Debug", "Release"]
- build_hermesc_windows:
requires:
- prepare_hermes_workspace
- build_npm_package:
name: build_and_publish_npm_package
context: react-native-bot
release_type: "dry-run"
requires:
- build_hermesc_linux
- build_hermes_macos
- build_hermesc_windows
analysis:
Use CircleCI API to trigger releases (#32937) Summary: Changelog: [Internal] * Refactor release automation so it doesn't use intermediate tags to trigger the release workflow. Now, we POST to CircleCI's ["trigger pipeline" API](https://circleci.com/docs/api/v2/#operation/triggerPipeline) * This does have the con of needing to give CircleCI project permission for whoever wants to run a release as you'll need a token to trigger * See related discussion: https://github.com/reactwg/react-native-releases/discussions/7#discussioncomment-1836420 Description of changes: * Changes to config.yml allow us to use our POST data to trigger a certain workflow. There is no direct API to trigger a workflow, CircleCI only has an API to trigger pipelines, so the suggestion is to leverage conditionals: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2 * Update `bump-oss-version` to make the api call -- the instructions for running a release are still the same: https://github.com/facebook/react-native/wiki/Release-Process#creating-0minor0-rc0 * Would be good to make this a yarn script as tido64 mentioned * Remove unused utilities now that we don't use intermediate tags like `publish-...` Pull Request resolved: https://github.com/facebook/react-native/pull/32937 Test Plan: Have this on a Github branch and tried this out locally: ## Running release script Running the bump-oss script (I had to hack it locally to be allowed to run on a non-release branch): {F694804729} * Link to resulting workflow: https://app.circleci.com/pipelines/github/facebook/react-native/11836 -- you can [verify that the parameters are the same as I passed](https://app.circleci.com/pipelines/github/facebook/react-native/11836/workflows/59ac0c86-5fe3-4d7a-80e9-c61129d49e9f/jobs/232388?invite=true#step-106-2) ## Other attempts triggering this workflow Notice that when I tried to run it on an actual release-branch (0.67-stable) but because the `config.yml` changes aren't on that branch, the job faisl | {F694804321} | ## Verifying the right workflows trigger on a regular push * Notice that the workflows "analysis" and "test" are still triggered on push (ie, the `unless:` clause isn't messing things up) {F694804320} Reviewed By: sota000 Differential Revision: D33715336 Pulled By: lunaleaps fbshipit-source-id: 82672d6d50768015bdfc9f4ea4d22aa801b84f06
2022-01-25 01:06:49 +03:00
unless: << pipeline.parameters.run_package_release_workflow_only >>
jobs:
# Run lints on every commit
- analyze_code
# Run code checks on PRs
- analyze_pr
# Gather coverage
- js_coverage
nightly:
Use CircleCI API to trigger releases (#32937) Summary: Changelog: [Internal] * Refactor release automation so it doesn't use intermediate tags to trigger the release workflow. Now, we POST to CircleCI's ["trigger pipeline" API](https://circleci.com/docs/api/v2/#operation/triggerPipeline) * This does have the con of needing to give CircleCI project permission for whoever wants to run a release as you'll need a token to trigger * See related discussion: https://github.com/reactwg/react-native-releases/discussions/7#discussioncomment-1836420 Description of changes: * Changes to config.yml allow us to use our POST data to trigger a certain workflow. There is no direct API to trigger a workflow, CircleCI only has an API to trigger pipelines, so the suggestion is to leverage conditionals: https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2 * Update `bump-oss-version` to make the api call -- the instructions for running a release are still the same: https://github.com/facebook/react-native/wiki/Release-Process#creating-0minor0-rc0 * Would be good to make this a yarn script as tido64 mentioned * Remove unused utilities now that we don't use intermediate tags like `publish-...` Pull Request resolved: https://github.com/facebook/react-native/pull/32937 Test Plan: Have this on a Github branch and tried this out locally: ## Running release script Running the bump-oss script (I had to hack it locally to be allowed to run on a non-release branch): {F694804729} * Link to resulting workflow: https://app.circleci.com/pipelines/github/facebook/react-native/11836 -- you can [verify that the parameters are the same as I passed](https://app.circleci.com/pipelines/github/facebook/react-native/11836/workflows/59ac0c86-5fe3-4d7a-80e9-c61129d49e9f/jobs/232388?invite=true#step-106-2) ## Other attempts triggering this workflow Notice that when I tried to run it on an actual release-branch (0.67-stable) but because the `config.yml` changes aren't on that branch, the job faisl | {F694804321} | ## Verifying the right workflows trigger on a regular push * Notice that the workflows "analysis" and "test" are still triggered on push (ie, the `unless:` clause isn't messing things up) {F694804320} Reviewed By: sota000 Differential Revision: D33715336 Pulled By: lunaleaps fbshipit-source-id: 82672d6d50768015bdfc9f4ea4d22aa801b84f06
2022-01-25 01:06:49 +03:00
unless: << pipeline.parameters.run_package_release_workflow_only >>
triggers:
- schedule:
cron: "0 20 * * *"
filters:
branches:
only:
- main
jobs:
- nightly_job
- prepare_hermes_workspace
- build_hermesc_linux:
requires:
- prepare_hermes_workspace
- build_hermes_macos:
requires:
- prepare_hermes_workspace
matrix:
parameters:
flavor: ["Debug", "Release"]
- build_hermesc_windows:
requires:
- prepare_hermes_workspace
- build_npm_package:
release_type: "nightly"
requires:
- build_hermesc_linux
- build_hermes_macos
- build_hermesc_windows