[workflow] Use Sphinx problem matcher on docs builds by ammaraskar · Pull Request #20325 · python/cpython

@ammaraskar Could you simulate some sphinx problem to see how it looks? (You can then add another commit to revert it).

I added two quick errors for testing, looks like -W has a fail-fast mechanism whereby the first warning causes the build to bail out so we don't see an error for the overline-underline mismatch.

Hmmm, giving that we are treating warnings as errors already, does it make sense to add the sphynx one? I find a bit misleading also that it only reports the first one (I understand why it happens), but if a contributor uses this new system to locate errors it would be very frustrating. Maybe I am missing some detail, though. What do you think?

Hmmm, giving that we are treating warnings as errors already, does it make sense to add the sphynx one?

Yeah, I was thinking this one is not as necessary as the compiler warning ones. Take a look now, I discovered there was --keep-going option along with Sphinx's -W that causes it to not fail-fast.

The main advantage of this would be that contributors who aren't that used to Sphinx/rst don't have to go looking through the logs to find out why the build is failing. It provides the errors in a more seamless way for a Github web editor workflow.

The main advantage of this would be that contributors who aren't that used to Sphinx/rst don't have to go looking through the logs to find out why the build is failing. It provides the errors in a more seamless way for a Github web editor workflow.

Yeah, that is true. I think there is some value in this.

Could you remove the failure changes so we can land this?