This is an archive of the discontinued LLVM Phabricator instance.

[zorg] Parse Ninja output.
Needs ReviewPublic

Authored by Meinersbur on May 2 2021, 12:32 AM.

Details

Reviewers
gkistanova
Summary

Parses the output from Ninja to split logs for each launched command that emits some output.

If there is any command that failed (indicated by ninja using a FAILED: prefix), emits only the failed commands. Otherwise it builds logs for any output (usually warnings or CMake re-runs).

See it in action e.g. at http://meinersbur.de:8011/#/builders/142/builds/514

Event Timeline

Meinersbur requested review of this revision.May 2 2021, 12:32 AM
Meinersbur created this revision.
Meinersbur added inline comments.May 2 2021, 12:35 AM
zorg/buildbot/commands/NinjaCommand.py
49

If logObserver is set, addLogObserver will fail. It had to be called after super().__init__. That is, the logObserver parameter is currently not used so I removed it.

Sorry for the delay.

Thanks for proposing a fix for the logObserver, Michael. At a quick glance it looks good.

Since NinjaCommand could be used for builds, tests, and installations, people may want to register different log observers depending on the nature of the step. The fact that it hasn't been used yet suggests that maybe it will not happen soon, still it would be great to have the ability from the beginning. What do you think? The proposed observer with the parseErrorLogs parser could be the default one.

In the mean time I'll stage this patch for a few days. Let's see it in action.

Almost forgot to mention.

zorg/buildbot/commands/NinjaCommand.py
6

Did you mean LineConsumerLogObserver here?

Meinersbur marked an inline comment as done.
  • Re-add logObserver
  • Correct import
  • Make LineConsumerLogObserver just the default observer.

Since NinjaCommand could be used for builds, tests, and installations, people may want to register different log observers depending on the nature of the step. The fact that it hasn't been used yet suggests that maybe it will not happen soon, still it would be great to have the ability from the beginning. What do you think? The proposed observer with the parseErrorLogs parser could be the default one.

The problem I see is that fixing something that is no checked for whether it is working will likely still not work, or whether it matches anyone's use case. E.g. someone might want to have both logObservers and the parseErrorLogs-derived ones. The logObserver argument could simply be re-added in that patch that needs it. As with LitTestCommand, CmakeCommand, AnnotatedCommand that don't even have logObservers arguments yet. Why does NinjaCommand need one, but not the others?

LitTestCommand parses LIT logs only and is not intended to parse anything else, AnnotatedCommand parses annotations only and is not intended to parse anything else. NinjaCommand could build (build logs), test (LIT logs), install (install logs).

Anyway, if you feel that strongly to defer this and consider it out of the scope of this patch, this is fine. I wouldn't make it a requirement.

I don't feel strongly about it (I already updated the patch)

Herald added a project: Restricted Project. · View Herald TranscriptNov 9 2022, 10:07 AM

I believe I commented this patch, but do not see my comments here. :(
Sorry for this.

This patch is staged.

You can see it in action in the build logs of these builders:

Please see if you are happy with the results.

The issues I see are:

  1. Issues parsing.

https://lab.llvm.org/staging/#/builders/40/builds/6944 step test-stage1-compiler reported cd /b/clang-with-thin-lto-wpd-ubuntu/llvm-project/clang/bindings/python && /usr/bin/cmake -E env CLANG_LIBRARY_PATH=/b/clang-with-thin-lto-wpd-ubuntu/build/stage1/lib /usr/bin/python3.7 -m unittest discover with the content

[stdout] ...............................................................................................................................
[stdout] ----------------------------------------------------------------------
[stdout] Ran 127 tests in 0.347s
[stdout] 
[stdout] OK

What's wrong with those 5 lines? Doesn't seem contain any warning or error.

Also please see there Running all regression tests which contains pretty much the whole test run printout along with the summary.

  1. Title wording.

There is mentioned above title cd /b/clang-with-thin-lto-wpd-ubuntu/llvm-project/clang/bindings/python && /usr/bin/cmake -E env CLANG_LIBRARY_PATH=/b/clang-with-thin-lto-wpd-ubuntu/build/stage1/lib /usr/bin/python3.7 -m unittest discover. It does not look informative.

Another example is in https://lab.llvm.org/staging/#/builders/200/builds/20070, which has a compile error. The title for this error looks like FAIL: Building CXX object unittests/Analysis/CMakeFiles/InlineAdvisorPlugin.dir/InlineAdvisorPlugin.cpp.o. Compiler reports it better - FAILED: unittests/Analysis/CMakeFiles/InlineAdvisorPlugin.dir/InlineAdvisorPlugin.cpp.o. Is it possible to use the compiler output for the title?

It might be trickier for warnings. But still WARNING: /home/buildbot-worker/minipc-1050ti-linux/rundir/llvm.src/llvm/lib/IR/Core.cpp might look better than Building CXX object lib/IR/CMakeFiles/LLVMCore.dir/Core.cpp.o (https://lab.llvm.org/staging/#/builders/200/builds/20068)?

And maybe if an error or a warning message is short and easy to parse, add it to the title? For example in https://lab.llvm.org/staging/#/builders/85/builds/8773 a warning looks like /home/buildbot/as-worker-4/publish-sphinx-docs/llvm-project/libc/docs/source_tree_layout.rst:62: WARNING: Title underline too short.; having a title similar to WARNING: /home/buildbot/as-worker-4/publish-sphinx-docs/llvm-project/libc/docs/source_tree_layout.rst:62: Title underline too short. would be great. This is fine not to do this, though. It could be a subject of a different patch.