mirrored from https://skia.googlesource.com/buildbot
-
Notifications
You must be signed in to change notification settings - Fork 65
/
.bazelrc
185 lines (162 loc) · 8.79 KB
/
.bazelrc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
# Copyright 2016 The Bazel Authors. All rights reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# If we prefix the directories with an underscore then they get ignored by Go tools.
# We are forced to do this until https://github.com/golang/go/issues/42965 is fixed.
build --symlink_prefix=_bazel_
# test inherits from build, so do not add test flags because that
# ends up invalidating the cache. https://github.com/bazelbuild/bazel/issues/13186
# test --symlink_prefix=_bazel_
build --workspace_status_command=bazel/get_workspace_status.sh
# Tags such as no-remote and no-cache have no effect without this. See
# https://github.com/bazelbuild/bazel/issues/8830.
build --experimental_allow_tags_propagation
# Pipe through the host system's *_EMULATOR_HOST environment variables to Bazel tests.
#
# We unset said environment variables under RBE because emulator tests under RBE spin up their own
# emulator instances.
build --test_env=BIGTABLE_EMULATOR_HOST
build --test_env=COCKROACHDB_EMULATOR_HOST
build --test_env=DATASTORE_EMULATOR_HOST
build --test_env=FIRESTORE_EMULATOR_HOST
build --test_env=PUBSUB_EMULATOR_HOST
build:remote --test_env=BIGTABLE_EMULATOR_HOST=
build:remote --test_env=COCKROACHDB_EMULATOR_HOST=
build:remote --test_env=DATASTORE_EMULATOR_HOST=
build:remote --test_env=FIRESTORE_EMULATOR_HOST=
build:remote --test_env=PUBSUB_EMULATOR_HOST=
# Pipe through GOOGLE_APPLICATION_CREDENTIALS for local tests. This breaks test hermeticity, so use
# judiciously. Most tests that depend on this variable should probably tagged with "no-remote".
#
# We clear this variable under build:remote because if set, it will most likely contain a path to a
# file in the host system, which could potentially point to a nonexisting file within the RBE
# container when Bazel is invoked with --config=remote.
build --test_env=GOOGLE_APPLICATION_CREDENTIALS
build:remote --test_env=GOOGLE_APPLICATION_CREDENTIALS=
# RBE-only environment variable for tests to detect whether they're running locally or on RBE.
build:remote --test_env=BAZEL_REMOTE=true
# Update the PATH environment variable under RBE to include the locations of various binaries
# installed in our custom RBE container toolchain image.
build:remote --test_env=PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/go/bin
# Rough equivalent of CGO_ENABLED=0 under Bazel. Produces statically-linked Go binaries, and
# filters out cgo code.
#
# See https://github.com/bazelbuild/rules_go/blob/master/go/modes.rst#id6.
#
# This prevents errors due to missing dynamic libraries, e.g. when running Bazel-built binaries
# inside Docker containers based on the gcr.io/skia-public/basealpine image.
build --@io_bazel_rules_go//go/config:pure
# Depending on how many machines are in the remote execution instance, setting
# this higher can make builds faster by allowing more jobs to run in parallel.
# Setting it too high can result in jobs that timeout, however, while waiting
# for a remote machine to execute them.
build:remote --jobs=50
# Set several flags related to specifying the platform, toolchain and java
# properties.
# These flags should only be used as is for the rbe-ubuntu16-04 container
# and need to be adapted to work with other toolchain containers.
build:remote --host_javabase=//bazel/rbe/generated/java:jdk
build:remote --javabase=//bazel/rbe/generated/java:jdk
build:remote --host_java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8
build:remote --java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8
build:remote --crosstool_top=//bazel/rbe/generated/cc:toolchain
build:remote --action_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1
# Platform flags:
# The toolchain container used for execution is defined in the target indicated
# by "extra_execution_platforms", "host_platform" and "platforms".
# More about platforms: https://docs.bazel.build/versions/master/platforms.html
build:remote --extra_toolchains=//bazel/rbe/generated/config:cc-toolchain
build:remote --extra_execution_platforms=//:rbe_custom_platform
build:remote --host_platform=//:rbe_custom_platform
build:remote --platforms=//:rbe_custom_platform
# Starting with Bazel 0.27.0 strategies do not need to be explicitly
# defined. See https://github.com/bazelbuild/bazel/issues/7480
build:remote --define=EXECUTOR=remote
# Enable remote execution so actions are performed on the remote systems.
build:remote --remote_executor=grpcs://remotebuildexecution.googleapis.com
# Enforce stricter environment rules, which eliminates some non-hermetic
# behavior and therefore improves both the remote cache hit rate and the
# correctness and repeatability of the build.
build:remote --incompatible_strict_action_env=true
# Set a higher timeout value, just in case.
build:remote --remote_timeout=3600
# Enable authentication. This will pick up application default credentials.
build:remote --google_default_credentials=true
# Use the RBE instance on the skia-infra-rbe GCP project.
build:remote --remote_instance_name projects/skia-infra-rbe/instances/default_instance
# Skip building the runfiles tree on the local system when building on RBE. This can be very slow,
# and is unnecessary for RBE builds because remote build actions will generate their own runfile
# tree anyway. See b/111951625.
build:remote --nobuild_runfile_links
# Note that running remote builds requires a service account key with the correct permissions. See
# instructions in //BAZEL_CHEATSHEET.md.
# Alias to build configurations below. This makes configuring things from
# the command line easier.
build --flag_alias=with_local_debugger=no//debugger-app/wasm_libs:use_debugger_from_container
build --flag_alias=with_local_wasm=no//jsfiddle/wasm_libs:use_libraries_from_container
build --flag_alias=shaders_local_canvaskit=no//shaders/wasm_libs:use_canvaskit_from_container
build --flag_alias=skottie_local_canvaskit=no//skottie/wasm_libs:use_canvaskit_from_container
# The rules_ts ruleset requires specifying a criteria for checking types in library dependencies.
# The below settings force rules_ts to honor the --skipLibCheck tsc flag specified in
# tsconfig.json (see https://www.typescriptlang.org/tsconfig#skipLibCheck).
build --@aspect_rules_ts//ts:skipLibCheck=honor_tsconfig
fetch --@aspect_rules_ts//ts:skipLibCheck=honor_tsconfig
query --@aspect_rules_ts//ts:skipLibCheck=honor_tsconfig
# Import user-specific Bazel configuration file if it exists. This file is gitignored.
#
# One of the purposes of this file is to override the "mayberemote" configuration so that it
# actually produces remote builds on RBE. See below for more on the "mayberemote" configuration.
try-import %workspace%/bazel/user/bazelrc
# The "mayberemote" config is used for scripted actions that *may* perform RBE builds with Bazel.
# For example, take the following Makefile:
#
# .PHONY: foo
# foo:
# bazel build --config=mayberemote //path/to:foo
#
# By default, --config=mayberemote does nothing, i.e. the above Makefile is equivalent to:
#
# .PHONY: foo
# foo:
# bazel build //path/to:foo
#
# If you want --config=mayberemote to be equivalent to --config=remote, please add the following
# line to your //bazel/user/bazelrc file:
#
# build:mayberemote --config=remote
#
# Then, the above Makefile will be equivalent to:
#
# .PHONY: foo
# foo:
# bazel build --config=remote //path/to:foo
#
# Some good example uses of --config=mayberemote are the "gazelle" and "buildifier" Make targets
# defined in //Makefile, which some Skia Infrastructure engineers use on an almost daily basis.
#
# Rationale:
#
# - Makefiles, or any other scripted action, should never use --config=remote directly, as such
# Bazel invocations are impossible to run for users without RBE credentials, users working
# offline (e.g. on an airplane without WiFi), etc.
#
# - Scripted actions should not force local builds either (unless absolutely necessary), as that
# causes Bazel to discard its analysis cache if the user normally runs remote builds, which
# makes Bazel take longer.
#
# - As an alternative, a user could make all builds remote by default by adding a line such as
# "build --config=remote" to their //bazel/user/bazelrc file. However, this is limiting because
# there might be legitimate cases where one would want to run a local build.
#
# Bazel complains if --config=mayberemote is undefined, so a default "no-op" definition is needed.
build:mayberemote --color=auto # Does nothing: --color is "auto" by default.