iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-docs-cn/.circleci/bazel.common.rc

20 lines
733 B
Plaintext
Raw Normal View History

ci: use circleci windows preview (#31266) PR Close #31266
2019-07-25 10:47:02 -04:00
# Settings in this file should be OS agnostic. Use the bazel.<OS>.rc files for OS specific settings.
build: fix bazel repositories not cached on circleci (#28515) Previously all Bazel repositories were cached on CircleCI because the `experimental_repository_cache` flag has been specified and the given repository cache directory has been included in the CircleCI cache storage. The directory is currently still included in the CircleCI cache storage, but the `--repository_cache` flag is no longer specified, and the cache directory is basically empty all the time. The flag seems to have been removed accidentally within SHA c8b70ae8e4a878c8855249df82bf3a46ce6ea0e5. We should specifiy this flag on the CI again, so that Bazel doesn't need to install the Bazel managed node modules all the time. This would slow down analysis phase on CI; and also makes us dependent on the Yarn/NPM registry which often times out if we fetch a lot of dependencies. Also in order to make sure that cached Bazel repositories are also most of the time in sync with what's currently defined in the workspace, we need to update the cache key. PR Close #28515
2019-02-04 11:11:26 -05:00
ci: enable bazel remote caching on CircleCI (#21784) This should cause Bazel builds to be incremental, only re-building parts of Angular affected by changes since the last build. It also fixes a potential version skew, where CI was running the Bazel linter binaries in the ngcontainer docker image, but developers built them using the versions in WORKSPACE PR Close #21784
2018-01-25 12:55:27 -05:00
# Don't be spammy in the logs
ci: use no_output_timeout for long jobs (#31266) PR Close #31266
2019-07-25 10:40:05 -04:00
build --noshow_progress
ci: enable bazel remote caching on CircleCI (#21784) This should cause Bazel builds to be incremental, only re-building parts of Angular affected by changes since the last build. It also fixes a potential version skew, where CI was running the Bazel linter binaries in the ngcontainer docker image, but developers built them using the versions in WORKSPACE PR Close #21784
2018-01-25 12:55:27 -05:00
build: flatten esm5 sources before rollup (#23131) this is needed to update to latest rules_nodejs due to breaking change in https://github.com/bazelbuild/rules_nodejs/pull/172 It has the side-effect of correctly marking rxjs packages as side-effect-free PR Close #23131
2018-04-02 19:34:48 -04:00
# Print all the options that apply to the build.
# This helps us diagnose which options override others
# (e.g. /etc/bazel.bazelrc vs. tools/bazel.rc)
build --announce_rc
ci: enable bazel remote caching on CircleCI (#21784) This should cause Bazel builds to be incremental, only re-building parts of Angular affected by changes since the last build. It also fixes a potential version skew, where CI was running the Bazel linter binaries in the ngcontainer docker image, but developers built them using the versions in WORKSPACE PR Close #21784
2018-01-25 12:55:27 -05:00
# Retry in the event of flakes, eg. https://circleci.com/gh/angular/angular/31309
test --flaky_test_attempts=2
test(bazel): Run Angular test on RBE (#25370) PR Close #25370
2018-08-02 00:02:36 -04:00
# More details on failures
build --verbose_failures=true
ci: run acceptance tests on saucelabs with ivy (#34277) Currently we only run Saucelabs on PRs using the legacy View Engine build. Switching that build to Ivy is not trivial and there are various options: 1. Updating the R3 switches to use POST_R3 by default. At first glance, this doesn't look easy because the current ngtsc switch logic seems to be unidirectional (only PRE_R3 to POST_R3). 2. Updating the legacy setup to run with Ivy. This sounds like the easiest solution at first.. but it turns out to be way more complicated. Packages would need to be built with ngtsc using legacy tools (i.e. first building the compiler-cli; and then building packages) and View Engine only tests would need to be determined and filtered out. Basically it will result in re-auditing all test targets. This is contradictory to the fact that we have this information in Bazel already. 3. Creating a new job that runs tests on Saucelabs with Bazel. We specify fine-grained test targets that should run. This would be a good start (e.g. acceptance tests) and also would mean that we do not continue maintaining the legacy setup.. This commit implements the third option as it allows us to move forward with the general Bazel migration. We don't want to spend too much time on our legacy setup since it will be removed anyway in the future. PR Close #34277
2019-12-06 10:17:09 -05:00
# For saucelabs tests we don't want to enable flaky test attempts. Karma has its own integrated
# retry mechanism and we do not want to retry unnecessarily if Karma already tried multiple times.
test:saucelabs --flaky_test_attempts=1