angular-cn/.circleci/config.yml

984 lines
43 KiB
YAML
Raw Normal View History

# Configuration file for https://circleci.com/gh/angular/angular
# Note: YAML anchors allow an object to be re-used, reducing duplication.
# The ampersand declares an alias for an object, then later the `<<: *name`
# syntax dereferences it.
# See http://blog.daemonl.com/2016/02/yaml.html
# To validate changes, use an online parser, eg.
# http://yaml-online-parser.appspot.com/
# CircleCI configuration version
# Version 2.1 allows for extra config reuse features
# https://circleci.com/docs/2.0/reusing-config/#getting-started-with-config-reuse
version: 2.1
# We don't want to include the current branch name in the cache key because that would prevent
# PRs from being able to restore the cache since the branch names are always different for PRs.
# The cache key should only consist of dynamic values that change whenever something in the
# cache changes. For example:
# 1) yarn lock file changes --> cached "node_modules" are different.
# 2) bazel repository definitions change --> cached bazel repositories are different.
# Windows needs its own cache key because binaries in node_modules are different.
# **NOTE 1 **: If you change the cache key prefix, also sync the cache_key_fallback to match.
# **NOTE 2 **: Keep the static part of the cache key as prefix to enable correct fallbacks.
# See https://circleci.com/docs/2.0/caching/#restoring-cache for how prefixes work in CircleCI.
var_3: &cache_key v3-angular-node-10.16-{{ checksum "yarn.lock" }}-{{ checksum "WORKSPACE" }}-{{ checksum "packages/bazel/package.bzl" }}-{{ checksum "aio/yarn.lock" }}
var_4: &cache_key_fallback v3-angular-node-10.16-
var_3_win: &cache_key_win v5-angular-win-node-12.0-{{ checksum "yarn.lock" }}-{{ checksum "WORKSPACE" }}-{{ checksum "packages/bazel/package.bzl" }}-{{ checksum "aio/yarn.lock" }}
var_4_win: &cache_key_win_fallback v5-angular-win-node-12.0-
# Cache key for the Material unit tests job. **Note** when updating the SHA in the cache keys,
# also update the SHA for the "MATERIAL_REPO_COMMIT" environment variable.
var_5: &material_unit_tests_cache_key v5-angular-material-71955d2e194bfc5561f25daea16e68af266d6ff9
var_6: &material_unit_tests_cache_key_fallback v5-angular-material-
# Workspace initially persisted by the `setup` job, and then enhanced by `build-npm-packages` and
# `build-ivy-npm-packages`.
# https://circleci.com/docs/2.0/workflows/#using-workspaces-to-share-data-among-jobs
# https://circleci.com/blog/deep-diving-into-circleci-workspaces/
var_7: &workspace_location ~/
# Filter to run a job on builds for pull requests only.
var_8: &only_on_pull_requests
filters:
branches:
only:
- /pull\/\d+/
# Filter to skip a job on builds for pull requests.
var_9: &skip_on_pull_requests
filters:
branches:
ignore:
- /pull\/\d+/
# Filter to run a job on builds for the master branch only.
var_10: &only_on_master
filters:
branches:
only:
- master
# Executor Definitions
# https://circleci.com/docs/2.0/reusing-config/#authoring-reusable-executors
# **NOTE 1**: Pin to exact images using an ID (SHA). See https://circleci.com/docs/2.0/circleci-images/#using-a-docker-image-id-to-pin-an-image-to-a-fixed-version.
# (Using the tag in not necessary when pinning by ID, but include it anyway for documentation purposes.)
# **NOTE 2**: If you change the version of the docker images, also change the `cache_key` suffix.
# **NOTE 3**: If you change the version of the `*-browsers` docker image, make sure the
# `CI_CHROMEDRIVER_VERSION_ARG` env var (in `.circleci/env.sh`) points to a ChromeDriver
# version that is compatible with the Chrome version in the image.
executors:
default-executor:
parameters:
resource_class:
type: string
default: medium
docker:
- image: circleci/node:10.16@sha256:75c05084fff4afa3683a03c5a04a4a3ad95c536ff2439d8fe14e7e1f5c58b09a
resource_class: << parameters.resource_class >>
working_directory: ~/ng
browsers-executor:
parameters:
resource_class:
type: string
default: medium
docker:
# The browser docker image comes with Chrome and Firefox preinstalled. This is just
# needed for jobs that run tests without Bazel. Bazel runs tests with browsers that will be
# fetched by the Webtesting rules. Therefore for jobs that run tests with Bazel, we don't need a
# docker image with browsers pre-installed.
- image: circleci/node:10.16-browsers@sha256:d2a96fe1cbef51257ee626b5f645e64dade3e886f00ba9cb7e8ea65b4efe8db1
resource_class: << parameters.resource_class >>
working_directory: ~/ng
windows-executor:
working_directory: ~/ng
resource_class: windows.medium
# CircleCI windows VMs do have the GitBash shell available:
# https://github.com/CircleCI-Public/windows-preview-docs#shells
# But in this specific case we really should not use it because Bazel must not be ran from
# GitBash. These issues discuss why:
# https://github.com/bazelbuild/bazel/issues/5751
# https://github.com/bazelbuild/bazel/issues/5724#issuecomment-410194038
# https://github.com/bazelbuild/bazel/issues/6339#issuecomment-441600879
shell: powershell.exe -ExecutionPolicy Bypass
machine:
# Windows preview image that includes the following:
# - Visual Studio 2019 build tools
# - Node 12
# - yarn 1.17
# - Python 3 3.7.4
image: windows-server-2019-vs2019:201908-02
# Command Definitions
# https://circleci.com/docs/2.0/reusing-config/#authoring-reusable-commands
commands:
custom_attach_workspace:
description: Attach workspace at a predefined location
steps:
- attach_workspace:
at: *workspace_location
ci(docs-infra): fix failure in `aio_monitoring_stable` due to yarn version mismatch (#34451) The `aio_monitoring_stable` CI job is triggered as a cronjob on the master branch and its purpose is to run some e2e tests against the deployed stable version of the docs web-app at https://angular.io/. In order for the tests to be compatible with the deployed version of the web-app (which gets deployed from the stable branch), the stable branch is checked out in git as part of the CI job. Previously, we only checked out the `aio/` directory from the stable branch, leaving the rest of the code at master. This doesn't matter as long as the commands used to run the tests do not rely on code outside of `aio/`. However, it turns out that there _is_ code outside of `aio/` that affects the executed commands: It is our vendored version of yarn (in `third_party/github.com/yarnpkg/`), which overwrites the global yarn installed on the docker image on CI and must match the version range specified in `aio/package.json > engines`. Using the yarn version checked out from the master branch with the `aio/` code checked out from the stable branch can lead to failures such as [this one][1]. This commit fixes the problem by checking out both the `aio/` and `third_party/github.com/yarnpkg/` directories from the stable branch and re-running the steps to overwrite the global yarn executable with our own version from `third_party/github.com/yarnpkg/`. This ensures that the version of yarn used will be compatible with the version range specified in `aio/package.json > engines`. NOTE: We cannot checkout everything from the stable branch, since the CI config (`.circleci/config.yml` from the master branch) may try to run certain scripts (such as `.circleci/get-vendored-yarn-path.js`) that are not available on the stable branch. Therefore, we should only check out the necessary bits from the stable branch. [1]: https://circleci.com/gh/angular/angular/567315 PR Close #34451
2019-12-17 12:05:22 -05:00
# Overwrite the yarn installed in the docker container with our own version.
overwrite_yarn:
description: Overwrite yarn with our own version
steps:
- run:
ci(docs-infra): fix failure in `aio_monitoring_stable` due to yarn version mismatch (#34451) The `aio_monitoring_stable` CI job is triggered as a cronjob on the master branch and its purpose is to run some e2e tests against the deployed stable version of the docs web-app at https://angular.io/. In order for the tests to be compatible with the deployed version of the web-app (which gets deployed from the stable branch), the stable branch is checked out in git as part of the CI job. Previously, we only checked out the `aio/` directory from the stable branch, leaving the rest of the code at master. This doesn't matter as long as the commands used to run the tests do not rely on code outside of `aio/`. However, it turns out that there _is_ code outside of `aio/` that affects the executed commands: It is our vendored version of yarn (in `third_party/github.com/yarnpkg/`), which overwrites the global yarn installed on the docker image on CI and must match the version range specified in `aio/package.json > engines`. Using the yarn version checked out from the master branch with the `aio/` code checked out from the stable branch can lead to failures such as [this one][1]. This commit fixes the problem by checking out both the `aio/` and `third_party/github.com/yarnpkg/` directories from the stable branch and re-running the steps to overwrite the global yarn executable with our own version from `third_party/github.com/yarnpkg/`. This ensures that the version of yarn used will be compatible with the version range specified in `aio/package.json > engines`. NOTE: We cannot checkout everything from the stable branch, since the CI config (`.circleci/config.yml` from the master branch) may try to run certain scripts (such as `.circleci/get-vendored-yarn-path.js`) that are not available on the stable branch. Therefore, we should only check out the necessary bits from the stable branch. [1]: https://circleci.com/gh/angular/angular/567315 PR Close #34451
2019-12-17 12:05:22 -05:00
name: Overwrite yarn
command: |
ci(docs-infra): fix failure in `aio_monitoring_stable` due to yarn version mismatch (#34451) The `aio_monitoring_stable` CI job is triggered as a cronjob on the master branch and its purpose is to run some e2e tests against the deployed stable version of the docs web-app at https://angular.io/. In order for the tests to be compatible with the deployed version of the web-app (which gets deployed from the stable branch), the stable branch is checked out in git as part of the CI job. Previously, we only checked out the `aio/` directory from the stable branch, leaving the rest of the code at master. This doesn't matter as long as the commands used to run the tests do not rely on code outside of `aio/`. However, it turns out that there _is_ code outside of `aio/` that affects the executed commands: It is our vendored version of yarn (in `third_party/github.com/yarnpkg/`), which overwrites the global yarn installed on the docker image on CI and must match the version range specified in `aio/package.json > engines`. Using the yarn version checked out from the master branch with the `aio/` code checked out from the stable branch can lead to failures such as [this one][1]. This commit fixes the problem by checking out both the `aio/` and `third_party/github.com/yarnpkg/` directories from the stable branch and re-running the steps to overwrite the global yarn executable with our own version from `third_party/github.com/yarnpkg/`. This ensures that the version of yarn used will be compatible with the version range specified in `aio/package.json > engines`. NOTE: We cannot checkout everything from the stable branch, since the CI config (`.circleci/config.yml` from the master branch) may try to run certain scripts (such as `.circleci/get-vendored-yarn-path.js`) that are not available on the stable branch. Therefore, we should only check out the necessary bits from the stable branch. [1]: https://circleci.com/gh/angular/angular/567315 PR Close #34451
2019-12-17 12:05:22 -05:00
localYarnPath=`node ./.circleci/get-vendored-yarn-path.js`
sudo chmod a+x $localYarnPath
sudo ln -fs $localYarnPath /usr/local/bin/yarn
- run: node --version
- run: yarn --version
ci(docs-infra): fix failure in `aio_monitoring_stable` due to yarn version mismatch (#34451) The `aio_monitoring_stable` CI job is triggered as a cronjob on the master branch and its purpose is to run some e2e tests against the deployed stable version of the docs web-app at https://angular.io/. In order for the tests to be compatible with the deployed version of the web-app (which gets deployed from the stable branch), the stable branch is checked out in git as part of the CI job. Previously, we only checked out the `aio/` directory from the stable branch, leaving the rest of the code at master. This doesn't matter as long as the commands used to run the tests do not rely on code outside of `aio/`. However, it turns out that there _is_ code outside of `aio/` that affects the executed commands: It is our vendored version of yarn (in `third_party/github.com/yarnpkg/`), which overwrites the global yarn installed on the docker image on CI and must match the version range specified in `aio/package.json > engines`. Using the yarn version checked out from the master branch with the `aio/` code checked out from the stable branch can lead to failures such as [this one][1]. This commit fixes the problem by checking out both the `aio/` and `third_party/github.com/yarnpkg/` directories from the stable branch and re-running the steps to overwrite the global yarn executable with our own version from `third_party/github.com/yarnpkg/`. This ensures that the version of yarn used will be compatible with the version range specified in `aio/package.json > engines`. NOTE: We cannot checkout everything from the stable branch, since the CI config (`.circleci/config.yml` from the master branch) may try to run certain scripts (such as `.circleci/get-vendored-yarn-path.js`) that are not available on the stable branch. Therefore, we should only check out the necessary bits from the stable branch. [1]: https://circleci.com/gh/angular/angular/567315 PR Close #34451
2019-12-17 12:05:22 -05:00
# Initializes the CI environment by setting up common environment variables.
init_environment:
description: Initializing environment (setting up variables, overwriting Yarn)
steps:
- run: ./.circleci/env.sh
- overwrite_yarn
- run:
# Configure git as the CircleCI `checkout` command does.
# This is needed because we only checkout on the setup job.
# Add GitHub to known hosts
name: Configure git
command: |
mkdir -p ~/.ssh
echo 'github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==' >> ~/.ssh/known_hosts
git config --global url."ssh://git@github.com".insteadOf "https://github.com" || true
git config --global gc.auto 0 || true
# Normally this would be an individual job instead of a command.
# But startup and setup time for each invidual windows job are high enough to discourage
# many small jobs, so instead we use a command for setup unless the gain becomes significant.
setup_win:
description: Setup windows node environment
steps:
# Use the Linux workspace directly, as it already has checkout, rebased and node modules.
- custom_attach_workspace
# Install Bazel pre-requisites that aren't in the preconfigured CircleCI Windows VM.
- run: ./.circleci/windows-env.ps1
- run:
# Overwrite the yarn installed in the docker container with our own version.
name: Overwrite yarn with our own version
command: ./.circleci/windows-yarn-setup.ps1
- run: node --version
- run: yarn --version
- restore_cache:
keys:
- *cache_key_win
- *cache_key_win_fallback
# Reinstall to get windows binaries.
- run: yarn install --frozen-lockfile --non-interactive
- setup_circleci_bazel_config_win
# Install @bazel/bazel globally and use that for the first run.
# Workaround for https://github.com/bazelbuild/rules_nodejs/issues/894
- run: yarn global add @bazel/bazel@$env:BAZEL_VERSION
- run: bazel info
setup_circleci_bazel_config:
description: Set up CircleCI bazel configuration on Linux
steps:
- run: sudo cp .circleci/bazel.linux.rc $HOME/.bazelrc
setup_circleci_bazel_config_win:
description: Set up CircleCI bazel configuration on Windows
steps:
- run: copy .circleci\bazel.windows.rc $env:USERPROFILE\.bazelrc
- run: mkdir $env:APPDATA\gcloud
# We need ensure that the same default digest is used for encoding and decoding
# with openssl. Openssl versions might have different default digests which can
# cause decryption failures based on the openssl version. https://stackoverflow.com/a/39641378/4317734
- run: openssl aes-256-cbc -d -in .circleci\gcp_token -md md5 -out "$env:APPDATA\gcloud\application_default_credentials.json" -k "$env:CIRCLE_PROJECT_REPONAME"
setup_bazel_rbe:
description: Setup bazel RBE remote execution
steps:
# We need ensure that the same default digest is used for encoding and decoding
# with openssl. Openssl versions might have different default digests which can
# cause decryption failures based on the openssl version. https://stackoverflow.com/a/39641378/4317734
- run: openssl aes-256-cbc -d -in .circleci/gcp_token -md md5 -k "$CI_REPO_NAME" -out /home/circleci/.gcp_credentials
- run: echo "export GOOGLE_APPLICATION_CREDENTIALS=/home/circleci/.gcp_credentials" >> $BASH_ENV
- run: ./.circleci/setup-rbe.sh .bazelrc.user
notify_webhook_on_fail:
description: Notify a webhook about failure
parameters:
# `webhook_url_env_var` are secret env vars defined in CircleCI project settings.
# The URLs come from https://angular-team.slack.com/apps/A0F7VRE7N-circleci.
webhook_url_env_var:
type: env_var_name
steps:
- run:
when: on_fail
command: |
notificationJson="{\"text\":\":x: \`$CIRCLE_JOB\` job for $CIRCLE_BRANCH branch failed on build $CIRCLE_BUILD_NUM: $CIRCLE_BUILD_URL :scream:\"}"
curl --request POST --header "Content-Type: application/json" --data "$notificationJson" ${<< parameters.webhook_url_env_var >>}
# Job definitions
# Jobs can include parameters that are passed in the workflow job invocation.
# https://circleci.com/docs/2.0/reusing-config/#authoring-parameterized-jobs
jobs:
setup:
executor: default-executor
steps:
- checkout
- run:
name: Rebase PR on target branch
# After checkout, rebase on top of target branch.
command: >
if [[ -n "${CIRCLE_PR_NUMBER}" ]]; then
# User is required for rebase.
git config user.name "angular-ci"
git config user.email "angular-ci"
# Rebase PR on top of target branch.
node tools/rebase-pr.js angular/angular ${CIRCLE_PR_NUMBER}
else
echo "This build is not over a PR, nothing to do."
fi
# This cache is saved in the build-npm-packages so that Bazel cache is also included.
- restore_cache:
keys:
- *cache_key
- *cache_key_fallback
- init_environment
- run:
name: Running Yarn install
command: yarn install --frozen-lockfile --non-interactive
# Yarn's requests sometimes take more than 10mins to complete.
no_output_timeout: 45m
- run: yarn --cwd aio install --frozen-lockfile --non-interactive
# Make the bazel directories and add a file to them if they don't exist already so that
# persist_to_workspace does not fail.
- run: |
if [ ! -d ~/bazel_repository_cache ]; then
mkdir ~/bazel_repository_cache
touch ~/bazel_repository_cache/MARKER
fi
# Persist any changes at this point to be reused by further jobs.
# **NOTE**: To add new content to the workspace, always persist on the same root.
- persist_to_workspace:
root: *workspace_location
paths:
- ./ng
- ./bazel_repository_cache
lint:
executor: default-executor
steps:
- custom_attach_workspace
- init_environment
- run: 'yarn bazel:format -mode=check ||
(echo "BUILD files not formatted. Please run ''yarn bazel:format''" ; exit 1)'
# Run the skylark linter to check our Bazel rules
- run: 'yarn bazel:lint ||
(echo -e "\n.bzl files have lint errors. Please run ''yarn bazel:lint-fix''"; exit 1)'
- run: yarn gulp lint
- run: node tools/verify-codeownership
test:
executor:
name: default-executor
resource_class: xlarge
steps:
- custom_attach_workspace
- init_environment
- setup_circleci_bazel_config
# Setup remote execution and run RBE-compatible tests.
- setup_bazel_rbe
- run:
command: yarn bazel test //... --build_tag_filters=-ivy-only --test_tag_filters=-ivy-only
no_output_timeout: 20m
# Temporary job to test what will happen when we flip the Ivy flag to true
test_ivy_aot:
executor:
name: default-executor
resource_class: xlarge
steps:
- custom_attach_workspace
- init_environment
- setup_circleci_bazel_config
- setup_bazel_rbe
# We need to explicitly specify the --symlink_prefix option because otherwise we would
# not be able to easily find the output bin directory when uploading artifacts for size
# measurements.
- run:
command: yarn test-ivy-aot //... --symlink_prefix=dist/
no_output_timeout: 20m
# Publish bundle artifacts which will be used to calculate the size change. **Note**: Make
# sure that the size plugin from the Angular robot fetches the artifacts from this CircleCI
# job (see .github/angular-robot.yml). Additionally any artifacts need to be stored with the
# following path format: "{projectName}/{context}/{fileName}". This format is necessary
# because otherwise the bot is not able to pick up the artifacts from CircleCI. See:
# https://github.com/angular/github-robot/blob/master/functions/src/plugins/size.ts#L392-L394
- store_artifacts:
path: dist/bin/packages/core/test/bundling/hello_world/bundle.min.js
destination: core/hello_world/bundle
- store_artifacts:
path: dist/bin/packages/core/test/bundling/todo/bundle.min.js
destination: core/todo/bundle
- store_artifacts:
path: dist/bin/packages/core/test/bundling/hello_world/bundle.min.js.br
destination: core/hello_world/bundle.br
- store_artifacts:
path: dist/bin/packages/core/test/bundling/todo/bundle.min.js.br
destination: core/todo/bundle.br
# This job is currently a PoC for running tests on SauceLabs via bazel. It runs a subset of the
# tests in `legacy-unit-tests-saucelabs` (see
# [BUILD.bazel](https://github.com/angular/angular/blob/ef44f51d5/BUILD.bazel#L66-L92)).
#
# NOTE: This is currently limited to master builds only. See the `default_workflow` configuration.
saucelabs_view_engine:
executor:
name: default-executor
# In order to avoid the bottleneck of having a slow host machine, we acquire a better
# container for this job. This is necessary because we launch a lot of browsers concurrently
# and therefore the tunnel and Karma need to process a lot of file requests and tests.
resource_class: xlarge
steps:
- custom_attach_workspace
- init_environment
- setup_circleci_bazel_config
- setup_bazel_rbe
- run:
name: Run Bazel tests in saucelabs
# All web tests are contained within a single //:saucelabs_unit_tests_poc target
# for Saucelabs as running each set of tests as a separate target will attempt to acquire
# too many browsers on Saucelabs (7 per target currently) and some tests will always
# fail to acquire browsers. For example:
# 14 02 2019 19:52:33.170:WARN [launcher]: chrome beta on SauceLabs have not captured in 180000 ms, killing.
# //packages/forms/test:web_test_sauce TIMEOUT in 315.0s
command: |
./scripts/saucelabs/run-bazel-via-tunnel.sh \
--tunnel-id angular-${CIRCLE_BUILD_NUM}-${CIRCLE_NODE_INDEX} \
--username $SAUCE_USERNAME \
--key $(echo $SAUCE_ACCESS_KEY | rev) \
-- yarn bazel test //:saucelabs_unit_tests_poc --config=saucelabs
no_output_timeout: 20m
- notify_webhook_on_fail:
webhook_url_env_var: SLACK_DEV_INFRA_CI_FAILURES_WEBHOOK_URL
saucelabs_ivy:
executor:
name: default-executor
# In order to avoid the bottleneck of having a slow host machine, we acquire a better
# container for this job. This is necessary because we launch a lot of browsers concurrently
# and therefore the tunnel and Karma need to process a lot of file requests and tests.
resource_class: xlarge
steps:
- custom_attach_workspace
- init_environment
- setup_circleci_bazel_config
- setup_bazel_rbe
- run:
name: Run Bazel tests on Saucelabs
# Runs the //:saucelabs_tests target with Saucelabs and Ivy.
command: |
./scripts/saucelabs/run-bazel-via-tunnel.sh \
--tunnel-id angular-${CIRCLE_BUILD_NUM}-${CIRCLE_NODE_INDEX} \
--username $SAUCE_USERNAME \
--key $(echo $SAUCE_ACCESS_KEY | rev) \
-- yarn bazel test //:saucelabs_unit_tests --config=ivy --config=saucelabs
no_output_timeout: 20m
test_aio:
# Needed because the AIO tests and the PWA score test depend on Chrome being available.
executor: browsers-executor
steps:
- custom_attach_workspace
- init_environment
# Compile dependencies to ivy
# Running `ngcc` here (instead of implicitly via `ng build`) allows us to take advantage of
# the parallel, async mode speed-up (~20-25s on CI).
- run: yarn --cwd aio ngcc --properties es2015
# Build aio
- run: yarn --cwd aio build --progress=false
# Lint the code
- run: yarn --cwd aio lint
# Run unit tests
- run: yarn --cwd aio test --progress=false --watch=false
# Run e2e tests
- run: yarn --cwd aio e2e --configuration=ci
# Run PWA-score tests
- run: yarn --cwd aio test-pwa-score-localhost $CI_AIO_MIN_PWA_SCORE
# Run accessibility tests
- run: yarn --cwd aio test-a11y-score-localhost
# Check the bundle sizes.
- run: yarn --cwd aio payload-size
# Run unit tests for Firebase redirects
- run: yarn --cwd aio redirects-test
deploy_aio:
# Needed because before deploying the deploy-production script runs the PWA score tests.
executor: browsers-executor
steps:
- custom_attach_workspace
- init_environment
# Deploy angular.io to production (if necessary)
- run: setPublicVar_CI_STABLE_BRANCH
- run: yarn --cwd aio deploy-production
test_aio_local:
parameters:
viewengine:
type: boolean
default: false
# Needed because the AIO tests and the PWA score test depend on Chrome being available.
executor: browsers-executor
steps:
- custom_attach_workspace
- init_environment
# Build aio (with local Angular packages)
- run: yarn --cwd aio build-local<<# parameters.viewengine >>-with-viewengine<</ parameters.viewengine >>-ci
# Run unit tests
- run: yarn --cwd aio test --progress=false --watch=false
# Run e2e tests
- run: yarn --cwd aio e2e --configuration=ci
# Run PWA-score tests
- run: yarn --cwd aio test-pwa-score-localhost $CI_AIO_MIN_PWA_SCORE
# Check the bundle sizes.
- run: yarn --cwd aio payload-size aio-local<<# parameters.viewengine >>-viewengine<</ parameters.viewengine >>
test_aio_tools:
executor: default-executor
steps:
- custom_attach_workspace
- init_environment
# Install
- run: yarn --cwd aio install --frozen-lockfile --non-interactive
- run: yarn --cwd aio extract-cli-command-docs
# Run tools tests
- run: yarn --cwd aio tools-test
- run: ./aio/aio-builds-setup/scripts/test.sh
test_docs_examples:
parameters:
ivy:
type: boolean
default: false
executor:
# Needed because the example e2e tests depend on Chrome.
name: browsers-executor
resource_class: xlarge
parallelism: 5
steps:
- custom_attach_workspace
- init_environment
# Install aio
- run: yarn --cwd aio install --frozen-lockfile --non-interactive
- when:
condition: << parameters.ivy >>
steps:
# Rename the Ivy packages dist folder to "dist/packages-dist" as the AIO
# package installer picks up the locally built packages from that location.
# *Note*: We could also adjust the packages installer, but given we won't have
# two different folders of Angular distributions in the future, we should keep
# the packages installer unchanged.
- run: mv dist/packages-dist-ivy-aot dist/packages-dist
# Run examples tests. The "CIRCLE_NODE_INDEX" will be set if "parallelism" is enabled.
# Since the parallelism is set to "5", there will be five parallel CircleCI containers.
# with either "0", "1", etc as node index. This can be passed to the "--shard" argument.
- run: yarn --cwd aio example-e2e --setup --local <<# parameters.ivy >>--ivy<</ parameters.ivy >> --cliSpecsConcurrency=5 --shard=${CIRCLE_NODE_INDEX}/${CIRCLE_NODE_TOTAL} --retry 2
# This job should only be run on PR builds, where `CI_PULL_REQUEST` is not `false`.
aio_preview:
executor: default-executor
environment:
AIO_SNAPSHOT_ARTIFACT_PATH: &aio_preview_artifact_path 'aio/tmp/snapshot.tgz'
steps:
- custom_attach_workspace
- init_environment
- run: ./aio/scripts/build-artifacts.sh $AIO_SNAPSHOT_ARTIFACT_PATH $CI_PULL_REQUEST $CI_COMMIT
- store_artifacts:
path: *aio_preview_artifact_path
# The `destination` needs to be kept in synch with the value of
# `AIO_ARTIFACT_PATH` in `aio/aio-builds-setup/Dockerfile`
destination: aio/dist/aio-snapshot.tgz
- run: node ./aio/scripts/create-preview $CIRCLE_BUILD_NUM
# This job should only be run on PR builds, where `CI_PULL_REQUEST` is not `false`.
test_aio_preview:
# Needed because the test-preview script runs e2e tests and the PWA score test with Chrome.
executor: browsers-executor
steps:
- custom_attach_workspace
- init_environment
- run: yarn --cwd aio install --frozen-lockfile --non-interactive
- run:
name: Wait for preview and run tests
command: node aio/scripts/test-preview.js $CI_PULL_REQUEST $CI_COMMIT $CI_AIO_MIN_PWA_SCORE
# The `build-npm-packages` tasks exist for backwards-compatibility with old scripts and
# tests that rely on the pre-Bazel `dist/packages-dist` output structure (build.sh).
# Having multiple jobs that independently build in this manner duplicates some work; we build
# the bazel packages more than once. Even though we have a remote cache, these jobs will
# typically run in parallel so up-to-date outputs will not be available at the time the build
# starts.
# Build the view engine npm packages. No new jobs should depend on this.
build-npm-packages:
executor:
name: default-executor
resource_class: xlarge
steps:
- custom_attach_workspace
- init_environment
- setup_circleci_bazel_config
- setup_bazel_rbe
- run: node scripts/build-packages-dist.js
# Save the npm packages from //packages/... for other workflow jobs to read
- persist_to_workspace:
root: *workspace_location
paths:
- ng/dist/packages-dist
- ng/dist/zone.js-dist
# Save dependencies and bazel repository cache to use on subsequent runs.
- save_cache:
key: *cache_key
paths:
- "node_modules"
- "aio/node_modules"
- "~/bazel_repository_cache"
# Build the ivy npm packages.
build-ivy-npm-packages:
executor:
name: default-executor
resource_class: xlarge
steps:
- custom_attach_workspace
- init_environment
- setup_circleci_bazel_config
- setup_bazel_rbe
- run: node scripts/build-ivy-npm-packages.js
# Save the npm packages from //packages/... for other workflow jobs to read
- persist_to_workspace:
root: *workspace_location
paths:
- ng/dist/packages-dist-ivy-aot
# We run the integration tests outside of Bazel for now.
# They are a separate workflow job so that they can be easily re-run.
# When the tests are ported to bazel test targets, they should move to the "test"
# job above, as part of the bazel test command. That has flaky_test_attempts so the
# need to re-run manually should be alleviated.
# See comments inside the integration/run_tests.sh script.
integration_test:
executor:
# Needed because the integration tests expect Chrome to be installed (e.g cli-hello-world)
name: browsers-executor
# Note: we run Bazel in one of the integration tests, and it can consume >2G
# of memory. Together with the system under test, this can exhaust the RAM
# on a 4G worker so we use a larger machine here too.
resource_class: xlarge
parallelism: 4
steps:
- custom_attach_workspace
- init_environment
# Runs the integration tests in parallel across multiple CircleCI container instances. The
# amount of container nodes for this job is controlled by the "parallelism" option.
- run: ./integration/run_tests.sh ${CIRCLE_NODE_INDEX} ${CIRCLE_NODE_TOTAL}
# This job creates compressed tarballs (`.tgz` files) for all Angular packages and stores them as
# build artifacts. This makes it easy to try out changes from a PR build for testing purposes.
# More info CircleCI build artifacts: https://circleci.com/docs/2.0/artifacts
#
# NOTE: Currently, this job only runs for PR builds. See `publish_snapshot` for non-PR builds.
publish_packages_as_artifacts:
executor: default-executor
environment:
NG_PACKAGES_DIR: &ng_packages_dir 'dist/packages-dist'
NG_PACKAGES_ARCHIVES_DIR: &ng_packages_archives_dir 'dist/packages-dist-archives'
ZONEJS_PACKAGES_DIR: &zonejs_packages_dir 'dist/zone.js-dist'
ZONEJS_PACKAGES_ARCHIVES_DIR: &zonejs_packages_archives_dir 'dist/zone.js-dist-archives'
steps:
- custom_attach_workspace
- init_environment
# Publish `@angular/*` packages.
- run:
name: Create artifacts for @angular/* packages
command: ./scripts/ci/create-package-archives.sh $CI_BRANCH $CI_COMMIT $NG_PACKAGES_DIR $NG_PACKAGES_ARCHIVES_DIR
- store_artifacts:
path: *ng_packages_archives_dir
destination: angular
# Publish `zone.js` package.
- run:
name: Create artifacts for zone.js package
command: ./scripts/ci/create-package-archives.sh $CI_BRANCH $CI_COMMIT $ZONEJS_PACKAGES_DIR $ZONEJS_PACKAGES_ARCHIVES_DIR
- store_artifacts:
path: *zonejs_packages_archives_dir
destination: zone.js
# This job updates the content of repos like github.com/angular/core-builds
# for every green build on angular/angular.
publish_snapshot:
executor: default-executor
steps:
# See below - ideally this job should not trigger for non-upstream builds.
# But since it does, we have to check this condition.
- run:
name: Skip this job for Pull Requests and Fork builds
# Note: Using `CIRCLE_*` env variables (instead of those defined in `env.sh` so that this
# step can be run before `init_environment`.
command: >
if [[ -n "${CIRCLE_PR_NUMBER}" ]] ||
[[ "$CIRCLE_PROJECT_USERNAME" != "angular" ]] ||
[[ "$CIRCLE_PROJECT_REPONAME" != "angular" ]]; then
circleci step halt
fi
- custom_attach_workspace
- init_environment
# CircleCI has a config setting to force SSH for all github connections
# This is not compatible with our mechanism of using a Personal Access Token
# Clear the global setting
- run: git config --global --unset "url.ssh://git@github.com.insteadof"
- run:
name: Decrypt github credentials
# We need ensure that the same default digest is used for encoding and decoding with
# openssl. Openssl versions might have different default digests which can cause
# decryption failures based on the installed openssl version. https://stackoverflow.com/a/39641378/4317734
command: 'openssl aes-256-cbc -d -in .circleci/github_token -md md5 -k "${KEY}" -out ~/.git_credentials'
- run: ./scripts/ci/publish-build-artifacts.sh
aio_monitoring_stable:
# This job needs Chrome to be globally installed because the tests run with Protractor
# which does not load the browser through the Bazel webtesting rules.
executor: browsers-executor
steps:
- custom_attach_workspace
- init_environment
- run: setPublicVar_CI_STABLE_BRANCH
- run:
ci(docs-infra): fix failure in `aio_monitoring_stable` due to yarn version mismatch (#34451) The `aio_monitoring_stable` CI job is triggered as a cronjob on the master branch and its purpose is to run some e2e tests against the deployed stable version of the docs web-app at https://angular.io/. In order for the tests to be compatible with the deployed version of the web-app (which gets deployed from the stable branch), the stable branch is checked out in git as part of the CI job. Previously, we only checked out the `aio/` directory from the stable branch, leaving the rest of the code at master. This doesn't matter as long as the commands used to run the tests do not rely on code outside of `aio/`. However, it turns out that there _is_ code outside of `aio/` that affects the executed commands: It is our vendored version of yarn (in `third_party/github.com/yarnpkg/`), which overwrites the global yarn installed on the docker image on CI and must match the version range specified in `aio/package.json > engines`. Using the yarn version checked out from the master branch with the `aio/` code checked out from the stable branch can lead to failures such as [this one][1]. This commit fixes the problem by checking out both the `aio/` and `third_party/github.com/yarnpkg/` directories from the stable branch and re-running the steps to overwrite the global yarn executable with our own version from `third_party/github.com/yarnpkg/`. This ensures that the version of yarn used will be compatible with the version range specified in `aio/package.json > engines`. NOTE: We cannot checkout everything from the stable branch, since the CI config (`.circleci/config.yml` from the master branch) may try to run certain scripts (such as `.circleci/get-vendored-yarn-path.js`) that are not available on the stable branch. Therefore, we should only check out the necessary bits from the stable branch. [1]: https://circleci.com/gh/angular/angular/567315 PR Close #34451
2019-12-17 12:05:22 -05:00
name: Check out `aio/` and `third_party/github.com/yarnpkg/` from the stable branch
command: |
ci(docs-infra): fix failure in `aio_monitoring_stable` due to yarn version mismatch (#34451) The `aio_monitoring_stable` CI job is triggered as a cronjob on the master branch and its purpose is to run some e2e tests against the deployed stable version of the docs web-app at https://angular.io/. In order for the tests to be compatible with the deployed version of the web-app (which gets deployed from the stable branch), the stable branch is checked out in git as part of the CI job. Previously, we only checked out the `aio/` directory from the stable branch, leaving the rest of the code at master. This doesn't matter as long as the commands used to run the tests do not rely on code outside of `aio/`. However, it turns out that there _is_ code outside of `aio/` that affects the executed commands: It is our vendored version of yarn (in `third_party/github.com/yarnpkg/`), which overwrites the global yarn installed on the docker image on CI and must match the version range specified in `aio/package.json > engines`. Using the yarn version checked out from the master branch with the `aio/` code checked out from the stable branch can lead to failures such as [this one][1]. This commit fixes the problem by checking out both the `aio/` and `third_party/github.com/yarnpkg/` directories from the stable branch and re-running the steps to overwrite the global yarn executable with our own version from `third_party/github.com/yarnpkg/`. This ensures that the version of yarn used will be compatible with the version range specified in `aio/package.json > engines`. NOTE: We cannot checkout everything from the stable branch, since the CI config (`.circleci/config.yml` from the master branch) may try to run certain scripts (such as `.circleci/get-vendored-yarn-path.js`) that are not available on the stable branch. Therefore, we should only check out the necessary bits from the stable branch. [1]: https://circleci.com/gh/angular/angular/567315 PR Close #34451
2019-12-17 12:05:22 -05:00
localYarnDir=third_party/github.com/yarnpkg/
# Remove the directory to ensure there will be only one version available (the one
# checked out from the stable branch below).
rm -rf $localYarnDir
git fetch origin $CI_STABLE_BRANCH
ci(docs-infra): fix failure in `aio_monitoring_stable` due to yarn version mismatch (#34451) The `aio_monitoring_stable` CI job is triggered as a cronjob on the master branch and its purpose is to run some e2e tests against the deployed stable version of the docs web-app at https://angular.io/. In order for the tests to be compatible with the deployed version of the web-app (which gets deployed from the stable branch), the stable branch is checked out in git as part of the CI job. Previously, we only checked out the `aio/` directory from the stable branch, leaving the rest of the code at master. This doesn't matter as long as the commands used to run the tests do not rely on code outside of `aio/`. However, it turns out that there _is_ code outside of `aio/` that affects the executed commands: It is our vendored version of yarn (in `third_party/github.com/yarnpkg/`), which overwrites the global yarn installed on the docker image on CI and must match the version range specified in `aio/package.json > engines`. Using the yarn version checked out from the master branch with the `aio/` code checked out from the stable branch can lead to failures such as [this one][1]. This commit fixes the problem by checking out both the `aio/` and `third_party/github.com/yarnpkg/` directories from the stable branch and re-running the steps to overwrite the global yarn executable with our own version from `third_party/github.com/yarnpkg/`. This ensures that the version of yarn used will be compatible with the version range specified in `aio/package.json > engines`. NOTE: We cannot checkout everything from the stable branch, since the CI config (`.circleci/config.yml` from the master branch) may try to run certain scripts (such as `.circleci/get-vendored-yarn-path.js`) that are not available on the stable branch. Therefore, we should only check out the necessary bits from the stable branch. [1]: https://circleci.com/gh/angular/angular/567315 PR Close #34451
2019-12-17 12:05:22 -05:00
git checkout --force origin/$CI_STABLE_BRANCH -- aio/ $localYarnDir
# Overwrite yarn again to use the version from the checked out branch.
- overwrite_yarn
- run:
name: Run tests against https://angular.io/
command: ./aio/scripts/test-production.sh https://angular.io/ $CI_AIO_MIN_PWA_SCORE
- notify_webhook_on_fail:
webhook_url_env_var: SLACK_CARETAKER_WEBHOOK_URL
- notify_webhook_on_fail:
webhook_url_env_var: SLACK_DEV_INFRA_CI_FAILURES_WEBHOOK_URL
aio_monitoring_next:
# This job needs Chrome to be globally installed because the tests run with Protractor
# which does not load the browser through the Bazel webtesting rules.
executor: browsers-executor
steps:
- custom_attach_workspace
- init_environment
- run:
name: Run tests against https://next.angular.io/
command: ./aio/scripts/test-production.sh https://next.angular.io/ $CI_AIO_MIN_PWA_SCORE
- notify_webhook_on_fail:
webhook_url_env_var: SLACK_CARETAKER_WEBHOOK_URL
- notify_webhook_on_fail:
webhook_url_env_var: SLACK_DEV_INFRA_CI_FAILURES_WEBHOOK_URL
legacy-unit-tests-saucelabs:
executor:
name: default-executor
# In order to avoid the bottleneck of having a slow host machine, we acquire a better
# container for this job. This is necessary because we launch a lot of browsers concurrently
# and therefore the tunnel and Karma need to process a lot of file requests and tests.
resource_class: xlarge
steps:
- custom_attach_workspace
- init_environment
- run:
name: Preparing environment for running tests on Saucelabs.
command: |
setPublicVar KARMA_JS_BROWSERS $(node -e 'console.log(require("./browser-providers.conf").sauceAliases.CI_REQUIRED.join(","))')
setSecretVar SAUCE_ACCESS_KEY $(echo $SAUCE_ACCESS_KEY | rev)
- run:
name: Starting Saucelabs tunnel
command: ./scripts/saucelabs/start-tunnel.sh
background: true
- run: yarn tsc -p packages
- run: yarn tsc -p modules
- run: yarn bazel build //packages/zone.js:npm_package
# Waits for the Saucelabs tunnel to be ready. This ensures that we don't run tests
# too early without Saucelabs not being ready.
- run: ./scripts/saucelabs/wait-for-tunnel.sh
- run: yarn karma start ./karma-js.conf.js --single-run --browsers=${KARMA_JS_BROWSERS}
- run: ./scripts/saucelabs/stop-tunnel.sh
legacy-misc-tests:
executor: default-executor
steps:
- custom_attach_workspace
- init_environment
- run: yarn gulp check-cycle
# TODO: disabled because the Bazel packages-dist does not seem to have map files for
# the ESM5/ES2015 output. See: https://github.com/angular/angular/issues/27966
# - run: yarn gulp source-map-test
# Job to run unit tests from angular/components. Needs a browser since all
# component unit tests assume they're running in the browser environment.
material-unit-tests:
executor:
name: browsers-executor
resource_class: xlarge
steps:
- custom_attach_workspace
- init_environment
# Although RBE is configured below for the Material repo, also setup RBE in the Angular repo
# to provision Angular's GCP token into the environment variables.
- setup_bazel_rbe
# Restore the cache before cloning the repository because the clone script re-uses
# the restored repository if present. This reduces the amount of times the components
# repository needs to be cloned (this is slow and increases based on commits in the repo).
- restore_cache:
keys:
- *material_unit_tests_cache_key
- *material_unit_tests_cache_key_fallback
- run:
name: "Fetching Material repository"
command: ./scripts/ci/clone_angular_material_repo.sh
- run:
# Run yarn install to fetch the Bazel binaries as used in the Material repo.
name: Installing Material dependencies.
# TODO: remove this once the repo has been updated to use NodeJS v12 and Yarn 1.19.1.
# We temporarily ignore the "engines" because the Angular components repository has
# minimum dependency on NodeJS v12 and Yarn 1.19.1, but the framework repository uses
# older versions.
command: yarn --ignore-engines --cwd ${MATERIAL_REPO_TMP_DIR} install --frozen-lockfile --non-interactive
- save_cache:
key: *material_unit_tests_cache_key
paths:
# Material directory must be kept in sync with the `$MATERIAL_REPO_TMP_DIR` env variable.
# It needs to be hardcoded here, because env variables interpolation is not supported.
- "/tmp/material2"
- run:
name: "Setup Bazel RBE remote execution in Material repo"
command: |
./.circleci/setup-rbe.sh "${MATERIAL_REPO_TMP_DIR}/.bazelrc.user"
- run:
# Updates Material's `package.json` to refer to the `packages-dist` directory. Note
# that it's not necessary to perform a yarn install, as Bazel runs it automatically.
name: Setting up release packages.
command: node scripts/ci/update-deps-to-dist-packages.js ${MATERIAL_REPO_TMP_DIR}/package.json dist/packages-dist/
- run:
# Install TypeScript 3.7 and Tsickle 0.38.0.
name: Setting up TypeScript 3.7 and Tsickle 0.38.0
# TODO: remove this once the repo has been updated to use TypeScript 3.7 and
# Tsickle 0.38.0. Note that the components repository has a Yarn resolution to ensure
# that "dgeni-packages" uses a specific TypeScript version. This resolution causes the
# specified TS version to be a valid candidate for the "@angular/bazel" peer dependency.
# Ultimately, Yarn seems to use the TS version from the resolution for Angular Bazel.
# This causes a mismatch of TypeScript versions as tsickle will use the v3.7.4 version,
# while Angular Bazel uses any arbitrary version from the resolution (currently v3.6.4).
# Also note that we need to explicitly update `tsickle` because `angular/components`
# declared it as explicit dep, and their current version is not compatible with TS 3.7.
command: |
sed -i -E 's#(dgeni-packages/typescript": ").+"#\13.7.4"#' ${MATERIAL_REPO_TMP_DIR}/package.json
yarn --ignore-engines --cwd ${MATERIAL_REPO_TMP_DIR} add typescript@3.7.4 tsickle@0.38.0 --dev
- run:
name: "Running Material unit tests"
command: ./scripts/ci/run_angular_material_unit_tests.sh
test_zonejs:
executor:
name: default-executor
resource_class: xlarge
steps:
- custom_attach_workspace
- init_environment
- setup_circleci_bazel_config
- setup_bazel_rbe
# Install
- run: yarn --cwd packages/zone.js install --frozen-lockfile --non-interactive
# Run zone.js tools tests
- run: yarn --cwd packages/zone.js promisetest
- run: yarn --cwd packages/zone.js promisefinallytest
- run: yarn bazel build //packages/zone.js:npm_package &&
cp dist/bin/packages/zone.js/npm_package/dist/zone-mix.js ./packages/zone.js/test/extra/ &&
cp dist/bin/packages/zone.js/npm_package/dist/zone-patch-electron.js ./packages/zone.js/test/extra/ &&
yarn --cwd packages/zone.js electrontest
# Windows jobs
# Docs: https://circleci.com/docs/2.0/hello-world-windows/
test_win:
executor: windows-executor
steps:
- setup_win
- run:
# Ran into a command parsing problem where `-browser:chromium-local` was converted to
# `-browser: chromium-local` (a space was added) in https://circleci.com/gh/angular/angular/357511.
# Probably a powershell command parsing thing. There's no problem using a yarn script though.
command: yarn circleci-win-ve
no_output_timeout: 45m
# Save bazel repository cache to use on subsequent runs.
# We don't save node_modules because it's faster to use the linux workspace and reinstall.
- save_cache:
key: *cache_key_win
paths:
- "C:/Users/circleci/bazel_repository_cache"
test_ivy_aot_win:
executor: windows-executor
steps:
- setup_win
- run:
command: yarn circleci-win-ivy
no_output_timeout: 45m
workflows:
version: 2
default_workflow:
jobs:
- setup:
filters:
branches:
ignore: g3
- lint:
requires:
- setup
- test:
requires:
- setup
- test_ivy_aot:
requires:
- setup
- build-npm-packages:
requires:
- setup
- build-ivy-npm-packages:
requires:
- setup
- legacy-misc-tests:
requires:
- build-npm-packages
- legacy-unit-tests-saucelabs:
requires:
- setup
- saucelabs_ivy:
requires:
- test_ivy_aot
- saucelabs_view_engine:
# This job is currently a PoC and a subset of `legacy-unit-tests-saucelabs`. Running on
# master only to avoid wasting resources.
# TODO: Run this job on all branches (including PRs) as soon as it is not a PoC and
# we can remove the legacy saucelabs job.
<<: *only_on_master
requires:
- setup
- test_aio:
requires:
- setup
- deploy_aio:
requires:
- test_aio
- test_aio_local:
requires:
- build-npm-packages
- test_aio_local:
name: test_aio_local_viewengine
viewengine: true
requires:
- build-npm-packages
- test_aio_tools:
requires:
- build-npm-packages
- test_docs_examples:
requires:
- build-npm-packages
- test_docs_examples:
name: test_docs_examples_ivy
ivy: true
requires:
- build-ivy-npm-packages
- aio_preview:
# Only run on PR builds. (There can be no previews for non-PR builds.)
<<: *only_on_pull_requests
requires:
- setup
- test_aio_preview:
requires:
- aio_preview
- integration_test:
requires:
- build-npm-packages
- publish_packages_as_artifacts:
requires:
- build-npm-packages
- publish_snapshot:
# Note: no filters on this job because we want it to run for all upstream branches
# We'd really like to filter out pull requests here, but not yet available:
# https://discuss.circleci.com/t/workflows-pull-request-filter/14396/4
# Instead, the job just exits immediately at the first step.
requires:
# Only publish if tests and integration tests pass
- test
- test_ivy_aot
- integration_test
- saucelabs_ivy
# Only publish if `aio`/`docs` tests using the locally built Angular packages pass
- test_aio_local
- test_aio_local_viewengine
- test_docs_examples
- test_docs_examples_ivy
# Get the artifacts to publish from the build-packages-dist job
# since the publishing script expects the legacy outputs layout.
- build-npm-packages
- build-ivy-npm-packages
- legacy-unit-tests-saucelabs
- legacy-misc-tests
- material-unit-tests:
requires:
- build-npm-packages
- test_zonejs:
requires:
- setup
# Windows Jobs
# These are very slow so we run them on non-PRs only for now.
# TODO: remove the filter when CircleCI makes Windows FS faster.
# The Windows jobs are only run after their non-windows counterparts finish successfully.
# This isn't strictly necessary as there is no artifact dependency, but helps economize
# CI resources by not attempting to build when we know should fail.
- test_win:
<<: *skip_on_pull_requests
requires:
- test
- test_ivy_aot_win:
<<: *skip_on_pull_requests
requires:
- test_ivy_aot
aio_monitoring:
jobs:
- setup
- aio_monitoring_stable:
requires:
- setup
- aio_monitoring_next:
requires:
- setup
triggers:
- schedule:
<<: *only_on_master
# Runs AIO monitoring jobs at 10:00AM every day.
cron: "0 10 * * *"