summaryrefslogtreecommitdiffhomepage
path: root/.bazelrc
AgeCommit message (Collapse)Author
2021-01-07Add ARM smoke testAndrei Vagin
make BAZEL_CONFIG=aarch64 arm-qemu-smoke-test Signed-off-by: Andrei Vagin <avagin@gmail.com>
2020-12-30Remove remote execution support.Adin Scannell
PiperOrigin-RevId: 349616845
2020-12-01Drop jobs for bazel remote execution.Adin Scannell
PiperOrigin-RevId: 345147980
2020-10-23[bazel] Increase number of jobs back to 300Ayush Ranjan
PiperOrigin-RevId: 338739277
2020-10-22[bazel] Reduce number of jobs to 100.Ayush Ranjan
PiperOrigin-RevId: 338517024
2020-10-19Remove now unused remote3 configurations.Adin Scannell
PiperOrigin-RevId: 337968219
2020-10-19Remove legacy bazel configurations.Adin Scannell
Using the newer bazel rules necessitates a transition from proto1 to proto2. In order to resolve the incompatibility between proto2 and gogoproto, the cri runtimeoptions proto must be vendored. Further, some of the semantics of bazel caching changed during the transition. It is now necessary to: - Ensure that :gopath depends only on pure library targets, as the propagation of go_binary build attributes (pure, static) will affected the generated files (though content remains the same, there are conflicts with respect to the gopath). - Update bazel.mk to include the possibility of binaries in the bazel-out directory, as it will now put runsc and others there. This required some refinements to the mechanism of extracting paths, since some the existing regex resulted in false positives. - Change nogo rules to prevent escape generation on binary targets. For some reason, the newer version of bazel attempted to run the nogo analysis on the binary targets, which fails due to the fact that objdump does not work on the final binary. This must be due to a change in the semantics of aspects in bazel3. PiperOrigin-RevId: 337958324
2020-07-30Double the number of jobs used by RBE.Adin Scannell
PiperOrigin-RevId: 324022546
2020-07-28Use the appropriate remote configuration.Adin Scannell
PiperOrigin-RevId: 323646156
2020-07-27Enable RBE for standard-tests.Adin Scannell
PiperOrigin-RevId: 323454998
2020-04-28Use existing bazeldefs with top-level BUILD file.Adin Scannell
PiperOrigin-RevId: 308901116
2020-01-27Standardize on tools directory.Adin Scannell
PiperOrigin-RevId: 291745021
2020-01-23Try running kythe build on RBE.Brad Burlage
Also add our RBE project/instance to the --config=remote defaults. PiperOrigin-RevId: 291201426
2019-12-06Build with C++17Michael Pratt
This will require a reasonably modern toolchain. I've put minimum compiler versions in the README based on versions in https://en.cppreference.com/w/cpp/compiler_support that have mostly complete language and library support. The minimum Bazel version bump is unrelated, but 0.28 is definitely not supported anymore. Please report issues on gvisor.dev/issue/1349. Fixes #1349 PiperOrigin-RevId: 284274250
2019-09-10Fix `runsc --version` and add a test.Nicolas Lacasse
We need to include the `--stamp` flag in `tools/workspace_status.sh` for the version to be picked up by the linker. Not sure why. Also changes the VERSION string to STABLE_VERSION, which will cause the program to be re-linked if the string changes. Fixes #830
2019-08-13Bump Bazel to v0.28.0Nicolas Lacasse
The new version has a change in behavior when using a custom platform: * Old behavior: rules that don't require a toolchain used host_platform, no matter what execution platforms are specified. * New behavior: rules that don't require a toolchain use standard platform resolution that starts with execution platforms. As part of this change, we cannot use the "extra_exectution_platforms" flag provided by the default bazelrc. I got rid of the default bazelrc file, and made our custom .bazelrc as minimal as possible. PiperOrigin-RevId: 263176802
2019-06-03Update straggling copyright holderMichael Pratt
Updates #209 PiperOrigin-RevId: 251289513
2019-04-05Make it easier for humans to use RBE, and maintain our bazelrc.Nicolas Lacasse
This CL merges all RBE-specific configuration from .bazelrc_rbe into .bazelrc so that it will be picked up by default by users running bazel. It also checks in a bazelrc from the upstream bazel-toolchains repository, and imports that into our repo-specific .bazelrc. This makes it easier to maintain and update the bazelrc going forward. Documentation was added to the README. PiperOrigin-RevId: 242208733 Change-Id: Iea32de9be85b024bd74f88909b56b2a8ab34851a
2018-11-06Move bazelrc to new locationMichael Pratt
Bazel 0.18 moved the workspace bazelrc location from //tools/bazel.rc to //.bazelrc. The old location will be dropped by a future version of bazel. This bumps the minimum required version of bazel to 0.18. More context: https://groups.google.com/forum/#!msg/bazel-discuss/ycDacctX2vw/EGFxGLibAgAJ PiperOrigin-RevId: 220338084 Change-Id: Ib6fa83a4a0f89e8e898d67152c7bd429e0b9b21e