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

39 lines
1.8 KiB
Plaintext
Raw Normal View History

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
# These options are enabled when running on CI
# We do this by copying this file to /etc/bazel.bazelrc at the start of the build.
build: update to Bazel 0.20 (#27394) refactor Bazel RBE configs PR Close #27394
2018-12-01 19:08:15 -05:00
# See documentation in /docs/BAZEL.md
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: 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
# Save downloaded repositories in a location that can be cached by CircleCI. This helps us
# speeding up the analysis time significantly with Bazel managed node dependencies on the CI.
build --repository_cache=/home/circleci/bazel_repository_cache
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
# Workaround https://github.com/bazelbuild/bazel/issues/3645
# Bazel doesn't calculate the memory ceiling correctly when running under Docker.
ci: double our cores on CircleCI (#22641) This should cut our build time in ~half, assuming it's widely parallel. See https://circleci.com/docs/2.0/configuration-reference/#resource_class Also enable bazel repository caching, and store the external repositories in the CircleCI cache for later builds. PR Close #22641
2018-03-07 20:26:03 -05:00
# Limit Bazel to consuming resources that fit in CircleCI "xlarge" class
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
# https://circleci.com/docs/2.0/configuration-reference/#resource_class
ci: double our cores on CircleCI (#22641) This should cut our build time in ~half, assuming it's widely parallel. See https://circleci.com/docs/2.0/configuration-reference/#resource_class Also enable bazel repository caching, and store the external repositories in the CircleCI cache for later builds. PR Close #22641
2018-03-07 20:26:03 -05:00
build --local_resources=14336,8.0,1.0
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
build: use remote actions for TS/NG compilations on CircleCI (#31471) PR Close #31471
2019-07-09 13:36:51 -04:00
# We have seen some flakiness in using TS workers on CircleCI
# https://angular-team.slack.com/archives/C07DT5M6V/p1562693245183400
# > failures like `ERROR: /home/circleci/ng/packages/core/test/BUILD.bazel:5:1:
# > Compiling TypeScript (devmode) //packages/core/test:test_lib failed: Worker process did not return a WorkResponse:`
# > I saw that issue a couple times today.
# > Example job: https://circleci.com/gh/angular/angular/385517
# We expect that TypeScript compilations will parallelize wider than the number of local cores anyway
# so we should saturate remote workers with TS compilations
ci: use local strategy for AngularTemplateCompile and TypescriptCompile on CI (#32112) PR Close #32112
2019-08-12 17:10:01 -04:00
build --strategy=AngularTemplateCompile=local
build --strategy=TypeScriptCompile=local