-
-
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
Find a way to avoid redundant CI workflow builds of cpython just to test Docs #435
Comments
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? |
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:
Against:
|
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. |
(See also #459.) |
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.
The text was updated successfully, but these errors were encountered: