You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Find a way to avoid redundant CI workflow builds of cpython just to test Docs #435
Currently the GitHub CI workflow for doc seems to first do its own build of cpython before attempting to build the docs. While that may be necessary for correct running of doctests or other reasons, it seems wasteful and time-consuming when cpython is already being built in other CI workflows. It would be great if someone could find a way to avoid unnecessary builds by perhaps combining the workflows in some way. See .github/workflows in the cpython repo.
Need to check if there are limits on total size of artifacts stored. In any case we don't need to keep them longer for a day, default is something like 90 days.
Bit of extra time for starting up new jobs
Couple of other ideas:
The build could be moved inside the main workflow as a new step after the main build/tests. Can still be run only when docs files change.
For:
No need to build twice
Against:
Doesn't run in parallel
If main tests fail, docs build/test won't run
Makes the main workflow longer
While that may be necessary for correct running of doctests or other reasons, ...
Alternatively, that "may" suggests maybe we don't need to build Python from source. If not, we can use a GitHub Actions version:
For:
Much faster to install
Can keep parallel builds
Can test docs even if main tests fail
Can use a GitHub Actions 3.11-dev to test on latest alpha/beta/RC
Need to check if there are limits on total size of artifacts stored. In any case we don't need to keep them longer for a day
Maybe, actions/cache then (docs)? It gives 10GB per repo with LRU autoeviction.
Also it works way faster than upload/download-artifact beause the latter packs/unpacks everything into a zip archive to make it downloadable not only by actions but by users too.
Activity
brandtbucher commentedon Mar 28, 2022
Unformed idea: I believe that...
Perhaps we could have a "build Python" action that provides a binary artifact to both the Docs and Ubuntu jobs?
hugovk commentedon Mar 28, 2022
Yes, there could be a build job that then uploads the build artifact using https://github.com/actions/upload-artifact and then two dependant jobs that use https://github.com/actions/download-artifact to fetch it and do their respective tests.
For:
Against:
Couple of other ideas:
The build could be moved inside the main workflow as a new step after the main build/tests. Can still be run only when docs files change.
For:
Against:
Alternatively, that "may" suggests maybe we don't need to build Python from source. If not, we can use a GitHub Actions version:
For:
3.11-devto test on latest alpha/beta/RCAgainst:
mainor PR brancharhadthedev commentedon Mar 28, 2022
Maybe, actions/cache then (docs)? It gives 10GB per repo with LRU autoeviction.
Also it works way faster than upload/download-artifact beause the latter packs/unpacks everything into a zip archive to make it downloadable not only by actions but by users too.
hugovk commentedon Jun 7, 2022
(See also #459.)
AA-Turner commentedon Aug 12, 2025
We now have split the docs and doctest jobs, only the latter needs to build CPython.