-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support parsing RemoteExecutionLog #193
Comments
The intersection between remote-apis (which is technically independent of Bazel, despite being hosted there), Bazel, and support tooling has always been tricky. We definitely shouldn't have Bazel-specific logic in this repository. That likely leads to...tools_remote being a wrapper that glues together Bazel-specific log parsing with this SDK? But I think you were just referred away from tools_remote... |
Indeed, tools_remote appears to be dead now. Turning this repo into a suitable base for solving this puzzle would be reasonable. Alternatively, standardising RemoteExecutionLog would also be reasonable, it's not very strongly tied to bazel, and any remote execution client could produce something similar. I'm not sure what's the most correct direction here. |
Right, the intention was that this repository would be the generic remote client solution that subsumes everything that tools_remote was, except for parts that are entirely Bazel-specific, e.g. help debugging Bazel invocations -- those would be left with tools_remote. And we always thought that RemoteExecutionLog falls in that category. You have a good point on RemoteExecutionLog being potentially standardizable... but for now, it is a part of Bazel, and defined there. Changing that would not be easy. Would using tools_remote for Bazel-specific debugging, and using this repository for everything else work for you? |
One of the tiny number of things https://github.com/bazelbuild/tools_remote can do and these tools can't is parse the RemoteExecutionLog. It would be nice to figure out a solution to that.
Annoyingly, that proto isn't part of github.com/bazelbuild/remote-apis so this is a more thorny puzzle than just implementing the (fairly simple) features.
The text was updated successfully, but these errors were encountered: