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

1338 строки
45 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
attach_hermes_workspace: &attach_hermes_workspace
attach_workspace:
at: *hermes_workspace_root
# -------------------------
# Cache Key Anchors
# -------------------------
# Anchors for the cache keys
cache_keys:
buck_cache_key: &buck_cache_key v3-buck-v2019.01.10.01-{{ checksum "scripts/circleci/buck_fetch.sh" }}}
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_cache_key: &hermes_cache_key v1-hermes-{{ .Environment.CIRCLE_JOB }}-{{ checksum "/tmp/hermes/hermesversion" }}
hermes_sdk_cache_key: &hermes_sdk_cache_key v1-hermes-{{ .Environment.CIRCLE_JOB }}-{{ checksum "sdks/.hermesversion" }}
hermes_windows_cache_key: &hermes_windows_cache_key v1-hermes-{{ .Environment.CIRCLE_JOB }}-{{ checksum "tmp/hermes/hermesversion" }}
pods_cache_key: &pods_cache_key v6-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 }}
# -------------------------
# 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: cimg/node:16.14
resource_class: "xlarge"
nodeprevlts:
<<: *defaults
docker:
- image: cimg/node:14.19
resource_class: "xlarge"
reactnativeandroid:
<<: *defaults
docker:
- image: reactnativecommunity/react-native-android:5.4
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 "13.3.0"
resource_class: macos.x86.medium.gen2
# -------------------------
# COMMANDS
# -------------------------
commands:
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" }}
install_buck_tooling:
steps:
- restore_cache:
keys:
- *buck_cache_key
- run:
name: Install BUCK
command: |
buck --version
# Install related tooling
if [[ ! -e ~/okbuck ]]; then
git clone https://github.com/uber/okbuck.git ~/okbuck --depth=1
fi
- save_cache:
paths:
- ~/buck
- ~/okbuck
key: *buck_cache_key
install_github_bot_deps:
steps:
- run:
name: "Yarn: Install dependencies (GitHub bots)"
command: cd bots && yarn install --non-interactive --cache-folder ~/.cache/yarn
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
download_buck_dependencies:
steps:
- run:
name: Download Dependencies Using Buck
command: ./scripts/circleci/buck_fetch.sh
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:
- install_github_bot_deps
- 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_sdk_cache_span:
parameters:
steps:
type: steps
steps:
- run:
name: Setup Hermes cache
command: |
HERMES_VERSION_FILE="sdks/.hermesversion"
if [ ! -f "$HERMES_VERSION_FILE" ]; then
git ls-remote https://github.com/facebook/hermes main | cut -f 1 > $HERMES_VERSION_FILE
fi
- restore_cache:
keys:
- *hermes_sdk_cache_key
- steps: << parameters.steps >>
- save_cache:
key: *hermes_sdk_cache_key
paths:
- sdks/hermesc
- sdks/hermes
# -------------------------
# 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
- install_github_bot_deps
# 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
- 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: Analyze Pull Request (pull-bot)
command: |
cd bots
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
DANGER_GITHUB_API_TOKEN="$PUBLIC_PULLBOT_GITHUB_TOKEN_A""$PUBLIC_PULLBOT_GITHUB_TOKEN_B" yarn danger ci --use-github-checks
when: always
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
# -------------------------
# 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
- 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
environment:
- REPORTS_DIR: "./reports/junit"
steps:
- checkout
- setup_artifacts
- setup_ruby
- run:
name: Run Ruby Tests
command: |
cd scripts
sh run_ruby_tests.sh
- run_yarn
- 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 cmake
- 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: Set USE_HERMES=1
command: echo "export USE_HERMES=1" >> $BASH_ENV
feat: Enable Hermes to work on iOS (#29914) Summary: This PR makes it possible to build iOS applications with Hermes. Note that it doesn't work with `use_frameworks!` just yet. Fixes https://github.com/facebook/react-native/issues/27845 (by downgrading iOS deployment target for RCT-Folly to 9.0) Fixes https://github.com/facebook/react-native/issues/28810 (as above) Checklist: - [x] Adjust release scripts to create Hermes bytecode bundle - [x] Release new Hermes npm package that includes iOS files (unreleased right now, if you want to try locally, you have to clone Hermes and `yarn link` its master to this project) - [x] Test on a new React Native application in both Debug and Release (Device) - [x] Test on an RNTester application in both Debug and Release (Device) - [x] Add missing `i386` to Hermes framework and enable Bitcode - [x] Inspect CI failures for possible regressions - [x] Resolve Folly issue as reported https://github.com/facebook/react-native/issues/27845 and https://github.com/facebook/react-native/issues/28810 - [x] Release new Hermes and test against it that everything works ## Changelog [IOS] [FEATURE] - Enable Hermes on iOS [INTERNAL] - Upgrade to CocoaPods 1.10.0 to resolve Xcode 12.0 issues [INTERNAL] - Upgrade to Xcode 12.0 on the CircleCI [INTERNAL] - Fix building RNTester in Release mode [INTERNAL] - Fix build-time errors of `libevent` with `use_frameworks!` [INTERNAL] - Introduce `USE_HERMES` variable and test all RNTester configurations on the CI [INTERNAL] - Do not fetch CocoaPods repository since we're using CDN anyway Pull Request resolved: https://github.com/facebook/react-native/pull/29914 Test Plan: Turn on `hermes_enabled` to true in your `Podfile`, install pods, and run the iOS application. Your app should be running Hermes now. Preview: (note "Engine: Hermes") <img width="395" alt="Screenshot 2020-09-09 at 19 22 32" src="https://user-images.githubusercontent.com/2464966/92631584-d7c01d80-f2d1-11ea-9b40-33d73db96a53.png"> Reviewed By: hramos Differential Revision: D24684845 Pulled By: cpojer fbshipit-source-id: 900cbe3bf9398a6fd4a773d552899a001bf5146b
2020-11-03 12:13:01 +03:00
- run:
name: Set BUILD_HERMES_SOURCE=1
command: echo "export BUILD_HERMES_SOURCE=1" >> $BASH_ENV
- run:
name: Setup the CocoaPods environment
command: bundle exec pod setup
- with_hermes_sdk_cache_span:
steps:
- with_rntester_pods_cache_span:
steps:
- run:
name: Generate RNTesterPods Workspace
command: 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
✅ 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 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
environment:
KOTLIN_HOME=third-party/kotlin
steps:
- checkout
- setup_artifacts
- run_yarn
# Validate Android SDK installation and packages
- run:
name: Validate Android SDK Install
command: ./scripts/validate-android-sdk.sh
# 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
# Install Buck
- install_buck_tooling
# Validate Android test environment (including Buck)
- run:
name: Validate Android Test Environment
command: ./scripts/validate-android-test-env.sh
- download_buck_dependencies
- download_gradle_dependencies
# Build and compile
- 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: Build & Test React Native using Gradle
command: ./gradlew buildAll
- run:
name: Compile Native Libs for Unit and Integration Tests
command: ./gradlew :ReactAndroid:packageReactNdkLibsForBuck -Pjobs=$BUILD_THREADS
Update ReactAndroid to use the AGP NDK Apis (#32443) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32443 This diff removes all the custom Gradle machinery to build the native code and delegates to AGP the triggering of the `ndk-build` command. This means that the native build will be now invoked with the `:ReactAndroid:externalNativeBuild<Variant>` task. An important thing to notice is that that task will always run, and will delegate to Make the compilation avoidance. If you invoke the task twice, the second time it will be significantly faster. On my machine this takes ~6/7 mins the first time, and 30 seconds the second time. There are some gotchas that are worth noting: * The native build will run on every build now. Given the complexity of our native build graph, even with an up-to-date build, Make will still take ~30 seconds on my machine to analyse all the targets and mention that there is no work to be done. I believe this could be impactful for local development experience. The mitigation I found was to apply an `abiFilter` to build only the ABI of the target device (e.g. arm64 for a real device and so on). This reduces the native build to ~10 seconds. * All the change to the `react-native-gradle-plugin` source will cause the Gradle tasks to be considered invalid. Therefore they will re-extract the header files inside the folders that are used by Make to compile, triggering a near-full rebuild. This can be a bit painful when building locally, if you plan to edit react-native-gradle-plugin and relaunch rn-tester (seems to be like an edge case scenario but worth pointing out). The mitigation here would be to invoke the tasks like ``` gw :packages:rn-tester:android:app:installHermesDebug -x prepareBoost -x prepareLibevent -x prepareGlog \ -x prepareJSC -x extractNativeDependencies -x generateCodegenArtifactsFromSchema \ -x generateCodegenSchemaFromJavaScript ``` Changelog: [Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task Reviewed By: ShikaSD Differential Revision: D31683721 fbshipit-source-id: fa85793c567796f4e04751e10503717a88cb0620
2021-11-01 15:56:47 +03:00
no_output_timeout: 30m
- run:
name: Build RN Tester for Release using Gradle
command: ./gradlew packages:rn-tester:android:app:assembleRelease
# Build JavaScript Bundle for instrumentation tests
- run:
name: Build JavaScript Bundle
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
# Wait for AVD to finish booting before running tests
- run:
name: Wait for Android Virtual Device
command: source scripts/android-setup.sh && waitForAVD
# -------------------------
# Run Android tests
- 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 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 retry3 timeout 300 buck build ReactAndroid/src/androidTest/buck-runner:instrumentation-tests --config build.threads=$BUILD_THREADS
# 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
# -------------------------
# Collect Results
- report_bundle_size:
platform: android
- 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
cd ~/okbuck
./tooling/junit/buck_to_junit.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 Template
# -------------------------
test_android_template:
executor: reactnativeandroid
steps:
- checkout
- run_yarn
- attach_workspace:
at: .
- run:
name: Create Android template project
command: |
REPO_ROOT=$(pwd)
PACKAGE=$(cat build/react-native-package-version)
PATH_TO_PACKAGE="$REPO_ROOT/build/$PACKAGE"
cd template
npm add $PATH_TO_PACKAGE
npm install
- run:
name: Build the template application
command: cd template/android/ && ./gradlew assembleDebug
# -------------------------
# JOBS: Test iOS Template
# -------------------------
test_ios_template:
executor: reactnativeios
environment:
- PROJECT_NAME: "iOSTemplateProject"
steps:
- checkout
- run_yarn
- attach_workspace:
at: .
- 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"
mkdir -p ~/tmp
cd ~/tmp
node "$REPO_ROOT/cli.js" init "$PROJECT_NAME" --template "$REPO_ROOT"
- run:
name: Build template project
command: |
xcodebuild build \
-workspace ~/tmp/$PROJECT_NAME/ios/$PROJECT_NAME.xcworkspace \
-scheme $PROJECT_NAME \
-sdk iphonesimulator
# -------------------------
# JOBS: Test iOS RNTester
# -------------------------
test_ios_rntester:
executor: reactnativeios
steps:
- checkout
- run_yarn
# 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/
- run:
name: Set USE_HERMES=1
command: echo "export USE_HERMES=1" >> $BASH_ENV
- run:
name: Set BUILD_HERMES_SOURCE=1
command: echo "export BUILD_HERMES_SOURCE=1" >> $BASH_ENV
- brew_install:
package: cmake
- with_hermes_sdk_cache_span:
steps:
- run:
name: Install CocoaPods dependencies
command: |
rm -rf packages/rn-tester/Pods
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
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:
name: Install Node
# Note: Version set separately for non-Windows builds, see above.
command: |
nvm install 16
nvm use 16
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:
name: Install Yarn
command: choco install yarn
- 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/
# -------------------------
# JOBS: Build hermesc
# -------------------------
prepare_hermes_workspace:
docker:
- image: debian:bullseye
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
- restore_cache:
key: *hermes_cache_key
- run:
name: Download Hermes tarball
command: |
node scripts/hermes/prepare-hermes-for-build
cp sdks/download/* $HERMES_WS_DIR/download/.
cp -r sdks/hermes/* $HERMES_WS_DIR/hermes/.
- save_cache:
key: *hermes_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_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_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_hermesc_macos:
executor: reactnativeios
environment:
- HERMES_WS_DIR: *hermes_workspace_root
steps:
- checkout
- *attach_hermes_workspace
- restore_cache:
key: *hermes_cache_key
- run:
name: Set up workspace
command: |
mkdir -p /tmp/hermes/osx-bin
cp ~/react-native/sdks/hermes-engine/utils/* "$HERMES_WS_DIR/hermes/utils/."
- run:
name: Install dependencies
command: |
brew install cmake
- run:
name: Build HermesC for macOS
command: |
if [ -f /tmp/hermes/osx-bin/hermesc ]; then
echo 'Skipping; Clean "/tmp/hermes/osx-bin" to rebuild.'
else
cd "$HERMES_WS_DIR/hermes"
./utils/build-mac-framework.sh
cp build_macosx/bin/hermesc /tmp/hermes/osx-bin/.
fi
- save_cache:
key: *hermes_cache_key
paths:
- /tmp/hermes/osx-bin/
- /tmp/hermes/hermes/destroot/
- /tmp/hermes/hermes/build_host_hermesc/
- /tmp/hermes/hermes/build_macosx/
- store_artifacts:
path: /tmp/hermes/osx-bin/
- persist_to_workspace:
root: /tmp/hermes/
paths:
- 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
executor: reactnativeios
steps:
- checkout
- run_yarn
- add_ssh_keys:
fingerprints:
- "1c:98:e0:3a:52:79:95:29:12:cd:b4:87:5b:41:e2:bb"
- run:
name: "Set new react-native version and commit changes"
command: |
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
node ./scripts/prepare-package-for-release.js -v << parameters.version >> -l << parameters.latest >>
build_npm_package:
parameters:
publish_npm_args:
type: string
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 HermesC binaries
command: |
mkdir -p ./sdks/hermesc ./sdks/hermesc/osx-bin ./sdks/hermesc/win64-bin ./sdks/hermesc/linux64-bin
cp -r $HERMES_WS_DIR/osx-bin/* ./sdks/hermesc/osx-bin/.
cp -r $HERMES_WS_DIR/win64-bin/* ./sdks/hermesc/win64-bin/.
cp -r $HERMES_WS_DIR/linux64-bin/* ./sdks/hermesc/linux64-bin/.
- run_yarn
- install_buck_tooling
- download_buck_dependencies
- 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.publish_npm_args >> ]
- equal: [ --nightly, << parameters.publish_npm_args >> ]
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.publish_npm_args >>
- 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
# START: Commitlies
# Provide a react-native package for this commit as a Circle CI release artifact.
- when:
condition:
equal: [ --dry-run, << parameters.publish_npm_args >> ]
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:
- install_github_bot_deps
- 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.publish_npm_args >> ]
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
# -------------------------
# 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_hermesc_macos:
requires:
- prepare_hermes_workspace
- build_hermesc_windows:
requires:
- prepare_hermes_workspace
- build_npm_package:
# Build a release package on every untagged commit, but do not publish to npm.
publish_npm_args: --dry-run
requires:
- build_hermesc_linux
- build_hermesc_macos
- build_hermesc_windows
- test_js:
run_disabled_tests: false
- test_android:
run_disabled_tests: false
- test_android_template:
requires:
- build_npm_package
- test_ios_template:
requires:
- build_npm_package
- test_ios_rntester
- test_ios:
run_unit_tests: true
# 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_hermesc_macos:
filters: *only_release_tags
requires:
- prepare_hermes_workspace
- 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
publish_npm_args: --release
filters: *only_release_tags
requires:
- build_hermesc_linux
- build_hermesc_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 from forks
- analyze_pr:
filters:
branches:
only: /^pull\/.*$/
# 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_hermesc_macos:
requires:
- prepare_hermes_workspace
- build_hermesc_windows:
requires:
- prepare_hermes_workspace
- build_npm_package:
publish_npm_args: --nightly
requires:
- build_hermesc_linux
- build_hermesc_macos
- build_hermesc_windows