Skip to content
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

Open
asuffield opened this issue Oct 2, 2020 · 3 comments
Open

support parsing RemoteExecutionLog #193

asuffield opened this issue Oct 2, 2020 · 3 comments

Comments

@asuffield
Copy link
Contributor

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.

@bergsieker
Copy link
Collaborator

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...

@asuffield
Copy link
Contributor Author

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.

@ola-rozenfeld
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants