Support for structured error output for failed actions
endobson opened this issue · comments
Description of the problem / feature request:
Allow custom rules to include structured error output when they fail.
Feature requests: what underlying problem are you trying to solve with this feature?
There are many rules that implement compilation of some set of files. When these fail they currently output information to stdout/stderr that is human parseable. Users then read the output, interpret what is wrong and fix it.
I would like to have tooling that sees that there was a failed build (through the Build Event Protocol), parses the failure, and integrates with the users editor to show the failures (I'm initially just working on vim quickfix).
To do this today I need the custom rule to output data in a human readable format that is also machine parseable. I would like to instead have a separate channel of some sorts where I can include structured output (e.g. json/protobuf) that could be parsed by down stream tooling.
Original SO question:
https://stackoverflow.com/questions/52049321/how-to-output-structured-error-information-in-bazel-rule
Interesting question. This seems similar to the recent Build Server Protocol (https://www.scala-lang.org/blog/2018/06/15/bsp.html - https://github.com/scalacenter/bsp/blob/master/docs/bsp.md), right? In the protocol, there's PublishDiagnosticsParams which is basically structured compiler output.
That seems very similar. One issue is that it doesn't include any method for extension that I can find. In particular all it seems to allow for enough structure so that an IDE can show the message but not enough for a compiler to encode suggested fixes (e.g. it looks like there is no variable name "indxe" did you mean "index", and have encoded a suggested delta to the source file).
@aiuto @laurentlb I'm categorizing this as a P4 FR ("if someone sends us a design and wants to implement it, I guess we could do it"), because it's unlikely that my team will ever have time to look into this and I'm not even sure if we're the right ones for this request and could review a design for this feature.
If you know someone better for this, please reassign.
Sounds good for me, although I'd like to revisit the priority in 6 or 9 months.
I would also like to surface machine-readable build failure logs—parsing stderr is decidedy icky.
I am mostly interested in the end result of the build once it completes, as opposed to a realtime event stream. For example, I'd like to know at the end of a build what all of the failures were and where they occurred. I would not be as interested in getting the failures one at a time as they occur during the build.
A couple approaches come to mind:
- A way of telling
bazelto write summarized build data after completion. - Augment the BuildFinished build event with failure data, if available. I could imagine extending this proto message.
I'm also interested in trying to get actionable error messages from the build log. Bazel knows what actions failed and what their output was, is there no way to get at that information other than parsing stderr?
Poking on this again as I'm actually working on getting my system that would need this into place.
I've currently got something that implements the BuildEventService, finds all the failed actions, opens up the File correspond to there stderr (out off the remote CAS), processes all the stderr, and then writes a file down so that vim can jump directly to the errors.
Is stderr/stdout still the only way to send data from actions to down stream systems in the case of failed actions? I'd be willing to change my rules to also include another output file if that would be included in the BEP.
Awesome. Any chance of creating a PR for your changes? It‘s been too quiet for too long on bazelbuild/vim-bazel#1
Posted over there, but I don't think it is what that issue wants.
This sounds like a change to extend the BEP or Bazel's frontend and doesn't have anything to do with execution strategies (as this would equally apply to local and remote strategies for example). Removing the team-Local-Exec label.
I put together a proposal a few months ago for adding structured compiler diagnostics (using the LSP format, but this could be extended to include fixes). It includes a prototype implementation in Bazel and sample code for getting diagnostics from scala compiles: https://docs.google.com/document/d/1KCQMvUMNVUBDyDmZJ1DB80tf21MVQdyWYS0Y9D_P0as/edit
I haven't had much time to push it forwards, but it could be a useful starting point for someone if they were interested.
Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.
@bazelbuild/triage Not stale