Repository navigation
Find a way to avoid redundant CI workflow builds of cpython just to test Docs #435
Description
Activity
Unformed idea: I believe that...
- Actions can share "artifacts" with each other.
- Actions can depend on other actions.
Perhaps we could have a "build Python" action that provides a binary artifact to both the Docs and Ubuntu jobs?
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:
- Just one CPython build
- Main and docs test can run in parallel
- And independently
Against:
- 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-devto test on latest alpha/beta/RC - Or can use deadsnakes to test on a nightly build
Against:
- Not testing against latest
mainor PR branch
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.
We now have split the docs and doctest jobs, only the latter needs to build CPython.
Reacted by Hugo van Kemenade
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.