commit | 6cea3fec5c0bdd65cbe25645aa738165688937f1 | [log] [tgz] |
---|---|---|
author | Xin <xingao267@users.noreply.github.com> | Wed Dec 05 11:04:00 2018 -0500 |
committer | GitHub <noreply@github.com> | Wed Dec 05 11:04:00 2018 -0500 |
tree | 67b90d150aa783edf93aa22200b218d71db66af1 | |
parent | 2095becc2b2a112a8823acf8f5ecf4a4f43346a0 [diff] |
Remove referring to repo itself when using own rules. (#257) This is to avoid creating infinite symlink expansion in the GCB job to create containers. The reason why this is happening is because in the our GCB job, we intentially set the bazel output_base to be the /workspace directory in order for some file mounting needed by the base-images-docker to work properly. /workspace is also where the source code of the repo is located on the GCB. The side effect of that is if we use bazel_toolchains as another external dependency (by adding @bazel_toolchains prefix in BUILD or WORKSPACE when loading bazel_toolchains repo's own rules), then an infinitie symlink expansion would occur: [start of symlink chain] /workspace/external/bazel_toolchains /workspace [end of symlink chain] We currently haven't found a way on GCB to avoid setting the output_base to be /workspace, and still keep the file mounting working. And putting the source code into /workspace is done by GCB and cannot be changed.
Travis CI | Bazel CI |
---|---|
https://github.com/bazelbuild/bazel-toolchains is a repository where Google hosts Bazel toolchain configs. These configs are required to configure Bazel to issue commands that will execute inside a Docker container via a remote execution environment.
These toolchain configs include:
Release information of toolchain configs can be found at: https://releases.bazel.build/bazel-toolchains.html.
This repository also hosts the skylark rule used to generate toolchain configs.