Github semi-recently introduced a new feature to Action workflows that allows you to install little regex handlers for logs that create pull request review comments for matches. These are called problem matchers and are great for prominently surfacing things like linter failures, warnings and other issues that won’t necessarily fail the build. They seem to be a port of an existing feature in VSCode extensions: https://code.visualstudio.com/docs/editor/tasks#_processing-task-output-with-problem-matchers
I’m particularly excited about the compiler warnings matchers since they seem to sneak in and then every once in a while someone makes a pull request to remove them. People that develop on Linux don’t tend to check the Windows warnings and vica-versa, and as long as the CI results are green no one really digs into the logs. This would allow them to be caught early in the review process.
@csabella suggested I post about this to gauge interest and make it more discover-able. I’ve created three pull requests with problem matchers for:
Catches errors and warnings from sphinx documentation builds. As a bonus this allows for a workflow whereby people making and reviewing documentation pull requests can fully work entirely from Github. Between this problem matcher and the netlify doc preview, we can be fairly sure the changes are good to go. (This one is not as important since https://github.com/python/cpython/commit/6aabb63d96845b3cb207d28d40bf0b78e171be75 which adds
-W, warnings-as-errors to the sphinx build but still provides errors in a more convenient place).
Catches warnings and errors generated from gcc. This is a straight forward port from the vscode-cpptools matcher.
This catches warnings and errors generated by our Windows builds. It is pulled straight out vscode itself.
I’ve created three Github workflow actions on the marketplace for each of these matchers:
This allows them to be used by the wider Github community and hopefully have a wider set of eyes looking at them to catch any issues.
Despite the error formats being relatively stable, relying on me to maintain the actions might be a little queasy for some of the core developers. In this case, it’s possible to commit the matchers (here’s an example of one) under the
.github folder on our repo and just use the local versions, I’d be happy to change over to that method if people feel necessary.