-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Speeding up the Docs / Docs CI job #459
Comments
cc @ned-deily re: #435
The big question is: do we need to build docs against Python from HEAD?
If not, I think using And we have options of what Python to test with [with approx setup timings]:
Building Python from source takes about 141s, so the above options are quite a bit quicker. But the patch saves much more time than ~141s in setup though.
The real big saving:
|
Thanks for finding the comment from #429!
I think this is a less compelling reason -- the Sphinx project tests with the latest development builds (currently deadsnakes' 3.11-dev nightly builds), so will catch deprecations there. Were there non-Sphinx deprecations you were referring to? (The link was to the collapsed summary page, so I'm not sure which deprecation warnings you're talking about). A |
doctest in CI job should be run with HEAD Python. |
Agreed, if they're just from third-party libraries it's not important. Much better to speed up the builds. |
python/cpython#93736 has been merged, thanks all. A |
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 ↩
Patch, Run 1, Run 2, Run 3. ↩
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. ↩
The text was updated successfully, but these errors were encountered: