read stdout_stderr.log from build steps to extract CMake / compiler warnings

[dirk-thomas]

Instead of using the whole console output which includes output from other steps of the process, e.g. testing as well as repeated stderr output from colcon.

Addresses #316 on ci.ros2.org. Fixes #473.

CI builds without this change (and a custom branch to produce a compiler warning):

• Linux
• Linux-aarch64
• macOS
• Windows

CI build with this change (the jobs will go away once this PR has been merged):

• Linux (still extracting the compiler warnings, but without the duplicate GCC warning)
• macOS: (still extracting the compiler warnings)
• Windows (still extracting the compiler warnings) (no compiler warning anymore)

False positive resolved by this patch:
Before: (test output was classified as a compiler warning)
After (the jobs will go away once this PR has been merged):

[nuclearsandwich]

These all hard-code the path ws. Do any builds randomly name the workspace path workspace or work space anymore?

When I was working on #447 I had to handle the elapsed time output (eg [0.554s] ...). Do any of the other warning parsers in use have an anchor to the start of the line (^)?

[dirk-thomas]

These all hard-code the path ws. Do any builds randomly name the workspace path workspace or work space anymore?

Good point, I already forgot we have that parameter: d34af48.

Do any of the other warning parsers in use have an anchor to the start of the line (^)?

I don't have an answer for this specific questions. But the above jobs show that compiler warnings are correctly being extracted - for GNU C, Clang, Clang-tidy, and MSBuild.

I have triggered another build to check if CMake warnings are captures too:
(one CMake warning as expected)

So I would conclude it is good as is.

[azeey]

https://ci.ros2.org/view/nightly/job/nightly_linux_repeated/1905/ and https://ci.ros2.org/view/nightly/job/nightly_osx_debug/1666/ failed I think because it was looking for log files in work space/..., but the files were in workspace/.... @dirk-thomas, can you verify?

[dirk-thomas]

When I was working on #447 I had to handle the elapsed time output (eg [0.554s] ...). Do any of the other warning parsers in use have an anchor to the start of the line (^)?

While this patch still extracts the warnings correctly the grouping contains the timestamp prefix from the log and as a consequence doesn't deduplicate same warnings (see https://ci.ros2.org/view/packaging/job/packaging_linux-centos/446/clang/#folderContent).

I don't think it is a feasible option to customize the Jenkins warnings handling. So the only viable option I can think of is generating the log files we need to parse without timestamp...

[dirk-thomas]

See colcon/colcon-output#33.