angular-cn/.bazelrc

106 lines
3.9 KiB
Plaintext
Raw Normal View History

# Load any settings specific to the current user
try-import .bazelrc.user
################################
# Settings for Angular team members only
################################
# To enable this feature check the "Remote caching" section in docs/BAZEL.md.
build:angular-team --remote_http_cache=https://storage.googleapis.com/angular-team-cache
###############################
# Typescript / Angular / Sass #
###############################
# Make compilation fast, by keeping a few copies of the compilers
# running as daemons, and cache SourceFile AST's to reduce parse time.
build --strategy=TypeScriptCompile=worker
build --strategy=AngularTemplateCompile=worker
# Enable debugging tests with --config=debug
test:debug --test_arg=--node_options=--inspect-brk --test_output=streamed --test_strategy=exclusive --test_timeout=9999 --nocache_test_results
###############################
# Filesystem interactions #
###############################
# Don't create symlinks like bazel-out in the project.
# These cause VSCode to traverse a massive tree, opening file handles and
# eventually a surprising failure with auto-discovery of the C++ toolchain in
# MacOS High Sierra.
# See https://github.com/bazelbuild/bazel/issues/4603
build --symlink_prefix=/
# Performance: avoid stat'ing input files
build --watchfs
# Turn off legacy external runfiles
run --nolegacy_external_runfiles
test --nolegacy_external_runfiles
###############################
# Release support #
# Turn on these settings with #
# --config=release #
###############################
# Releases should always be stamped with version control info
# This command assumes node on the path and is a workaround for
# https://github.com/bazelbuild/bazel/issues/4802
build:release --workspace_status_command="node ./tools/bazel_stamp_vars.js"
###############################
# Output #
###############################
# A more useful default output mode for bazel query
# Prints eg. "ng_module rule //foo:bar" rather than just "//foo:bar"
query --output=label_kind
# By default, failing tests don't print any output, it goes to the log file
test --test_output=errors
# Show which actions are run under workers,
# and print all the actions running in parallel.
# Helps to demonstrate that bazel uses all the cores on the machine.
build --experimental_ui
test --experimental_ui
################################
# Settings for CircleCI #
################################
# Bazel flags for CircleCI are in /.circleci/bazel.rc
################################
# Temporary Settings for Ivy #
################################
# to determine if the compiler used should be Ivy or ViewEngine one can use `--define=compile=aot` on
build(ivy): support alternate compilation modes to enable Ivy testing (#24056) Bazel has a restriction that a single output (eg. a compiled version of //packages/common) can only be produced by a single rule. This precludes the Angular repo from having multiple rules that build the same code. And the complexity of having a single rule produce multiple outputs (eg. an ngc-compiled version of //packages/common and an Ivy-enabled version) is too high. Additionally, the Angular repo has lots of existing tests which could be executed as-is under Ivy. Such testing is very valuable, and it would be nice to share not only the code, but the dependency graph / build config as well. Thus, this change introduces a --define flag 'compile' with three potential values. When --define=compile=X is set, the entire build system runs in a particular mode - the behavior of all existing targets is controlled by the flag. This allows us to reuse our entire build structure for testing in a variety of different manners. The flag has three possible settings: * legacy (the default): the traditional View Engine (ngc) build * local: runs the prototype ngtsc compiler, which does not rely on global analysis * jit: runs ngtsc in a mode which executes tsickle, but excludes the Angular related transforms, which approximates the behavior of plain tsc. This allows the main packages such as common to be tested with the JIT compiler. Additionally, the ivy_ng_module() rule still exists and runs ngc in a mode where Ivy-compiled output is produced from global analysis information, as a stopgap while ngtsc is being developed. PR Close #24056
2018-05-21 18:48:00 -04:00
# any bazel target. This is a temporary flag until codebase is permanently switched to Ivy.
build --define=compile=legacy
###############################
# Remote Build Execution support
# Turn on these settings with
# --config=remote
###############################
# Load default settings for Remote Build Execution
# When updating, the URLs of bazel_toolchains in packages/bazel/package.bzl
# may also need to be updated (see https://github.com/angular/angular/pull/27935)
import %workspace%/third_party/github.com/bazelbuild/bazel-toolchains/bazelrc/bazel-0.21.0.bazelrc
# Increase the default number of jobs by 50% because our build has lots of
# parallelism
build:remote --jobs=150
# Point to our custom execution platform; see tools/BUILD.bazel
build:remote --extra_execution_platforms=//tools:rbe_ubuntu1604-angular
build:remote --host_platform=//tools:rbe_ubuntu1604-angular
build:remote --platforms=//tools:rbe_ubuntu1604-angular
# Remote instance.
build:remote --remote_instance_name=projects/internal-200822/instances/default_instance
# Do not accept remote cache.
# We need to understand the security risks of using prior build artifacts.
build:remote --remote_accept_cached=false