Description
The short story
I think the Docs CI job can be faster, which would improve the contribution and review experience.
Long version
In the documentation team meeting we've been talking about a few workflow improvements. The Docs / Docs CI job is quite slow, taking around 15-20 minutes. From some quick testing, it seems this is largely due to that we use Python from HEAD and build Python in the job1, rather than a build with optimisation etc. Tests of my speed-up patch reduce the core docs job to ~3m15s2.
As a reviewer, a green tick is a quick signal that the syntax of the documentation is probably correct, and I don't need to be as thorough, whereas if the build fails I can look in the logs and point out the error and a potential fix to the proponenet of the PR.
I would suggest moving to actions/setup-python
for the Docs job, but I don't know if there's been prior discussion3 on this that I haven't been able to find, or if there are other reasons it makes sense to trade off speed for building Python from HEAD.
A
Footnotes
-
https://github.com/python/cpython/actions/workflows/doc.yml ↩
-
Find a way to avoid redundant CI workflow builds of cpython just to test Docs #435 discusses not building Python, but in the context of reusing another build from HEAD rather than an optimised version. ↩