| commit | e95641649b5b4d3c582c89daabfaabeb8189dd77 | [log] [tgz] |
|---|---|---|
| author | Ed Schouten <eschouten@apple.com> | Tue Apr 12 13:20:52 2022 |
| committer | GitHub <noreply@github.com> | Tue Apr 12 13:20:52 2022 |
| tree | 5723d7b4668802421abc83733dc0d7d43161913a | |
| parent | 04784f4a830cc0df1f419a492cde9fc323f728db [diff] |
Tidy up the semantics of Command.arguments[0] (#210) Bazel Buildfarm, Buildgrid and Buildbarn all perform resolution relative to the working directory of an action; not the input root directory. Instead of requiring that all implementations are updated, we should consider just altering the spec. Performing resolution relative to the input root directory can also be very tricky, as it means that argv[0] as visible to the calling process must also be rewritten. Applications may get confused otherwise. For example, consider the case where the working directory is "foo" and argv[0] is "bar/baz". In that case argv[0] as visible to the calling process must become "../bar/baz" or be made absolute. Making it absolute is inconsistent with what Bazel does right now. Attempting to keep it relative can be complex when symbolic links are involved. Furthermore, the specification doesn't mention what kind of path separators are used for argv[0]. The only reasonable solution here is to use path separators that are native to the host, as successive arguments also need to be provided in that form.
The Remote Execution API is an API that, at its most general, allows clients to request execution of binaries on a remote system. It is intended primarily for use by build systems, such as Bazel, to distribute build and test actions through a worker pool, and also provide a central cache of build results. This allows builds to execute faster, both by reusing results already built by other clients and by allowing many actions to be executed in parallel, in excess of the resource limits of the machine running the build.
There are a number of clients and services using these APIs, they are listed below.
These tools use the Remote Execution API to distribute builds to workers.
These applications implement the Remote Execution API to serve build requests from the clients above. These are then distributed to workers; some of these workers implement the Remote Worker API.
The Remote Execution APIs group hosts discussions related to the APIs in this repository.
Interested parties meet monthly via VC to discuss issues related to the APIs, and several contributors have organized occasional meetups, hack-a-thons, and summits. Joining the email discussion group will automatically add you to the Google Calendar invite for the monthly meeting.
The APIs in this repository refer to several general-purpose APIs published by Google in the Google APIs repository. You will need to refer to packages from that repository in order to generate code using this API. If you build the repository using the included BUILD files, Bazel will fetch the protobuf compiler and googleapis automatically.
The repository provides a rule that you can use in your WORKSPACE file to select which languages you are using. This allows you to depend on this repository without pulling in Go rules, for instance, if you aren't using Go rules.
For instance, if you only use Java in your project, add the following to your WORKSPACE file:
load("@bazel_remote_apis//:repository_rules.bzl", "switched_rules_by_language") switched_rules_by_language( name = "bazel_remote_apis_imports", java = True, )
You can find the complete list of supported languages in repository_rules.bzl.
The repository contains BUILD files to build the protobuf library with Bazel. If you wish to use them with your own project in Bazel, you will possibly want to declare cc_proto_library, java_proto_library, etc. rules that depend on them.
Other build systems will have to run protoc on the protobuf files, and link in the googleapis and well-known proto types, manually.
This repository contains the generated Go code for interacting with the API via gRPC. Get it with:
go get github.com/bazelbuild/remote-apis
Import it with, for example:
repb "github.com/bazelbuild/remote-apis/build/bazel/remote/execution/v2"
Enable the git hooks to automatically generate Go proto code on commit:
git config core.hooksPath hooks/
This is a local setting, so applies only to this repository.