Need option to fail when compile_commands.json couldn't be generatedFailed extracting commands for {target}\n Continuing gracefully...

[Carl Mueller-Roemer]

Continuing gracefully is nice for some things, like when a source file is missing, since we're not sure if we need that file. However sometimes I'm getting this error message:

Bazel aquery failed. Command: ...
Failed extracting commands for ...
Continuing gracefully...

This seems to come from the refresh.template.py:908.

The generated compile commands are empty, exit code is 0. In that case I would rather retry and/or fail the analysis pipeline. Currently I have to check for this warning message, which is not ideal.

[Chris Sauer]

Sorry I missed this issue, Carl. Just seeing now.

It was originally like that because people often have multiple targets within a refresh_compile_commands rule, and you don't want to fail out early because one target was in a bad state; the tool shouldn't require the code being edited to be in a good state. Instead, the thinking was, you want to get commands for all the targets you can. I know this code-editing use case is a bit different than yours w/ SonarQube, but it is a big use case for this tool.

Can we think together a bit on the conditions for which we'd like to signal failure here?

• Perhaps we really do want to fail early if a single aquery fails, rather than overwriting with an incomplete compile_commands.json. But then people might get stuck on unrelated failures from other people.
  • We could still continue but return a non-zero exit code in the end?
  • We could also, in this case, merge in the new entries with the existing file, to update things without wiping away potentially useful old commands.
• Or maybe the error condition is really that the resulting compile_commands.json will be fully empty, which I don't think anyone would consider a success case worth (over)writing a compile_commands.json. Perhaps we should add that as a new error case with a non-zero exit status?

One other structuring question: These aquerys are failing because there are errors in the corresponding BUILD files, right? Or are they something not already being caught by a build/test?

Thanks!
Chris

[Carl Mueller-Roemer]

Hi Chris,

Thank you for your feedback!

So actually for static analysis I'd like some robustness as well, it's not actually bad to continue on a single failed aquery from my point of view. With our large monorepo I can imagine it's helpful to still analyze whatever targets are there and print out an error message.

In my case I was getting a completely empty compile_commands.json (valid JSON, just an empty list), which I think is neither helpful for me, nor for any repositories in development. So my wish would be that we fail on an empty compile_commands.json. But if possible I'd keep going if there's just a single target failing.

It was an error from in our BUILD files, it's just that the analysis pipeline could have stopped then and there and reported an error, instead of continuing.

Cheers,

Carl

[Chris Sauer]

And likewise. Thanks for raising it--and thinking about it with me.
Just pushed a commit doing that, aligned with the last bullet above. And I'll have the merge/partial success logic in the back of my head for the future.