Skip to content
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

Improve CI jobs speed #13600

Open
fcollonval opened this issue Dec 15, 2022 · 4 comments · May be fixed by #15916
Open

Improve CI jobs speed #13600

fcollonval opened this issue Dec 15, 2022 · 4 comments · May be fixed by #15916

Comments

@fcollonval
Copy link
Member

Problem

The CI jobs are taking lots of time and their number is easily triggering queuing when multiple contributors are active simultaneously.

Proposed Solution

Ideas to speed the CI

  • Filter jobs with the modified paths (see GitHub syntax)
  • Set up a single Jupyter server for Jest unit tests to remove the current limitation of running test sequentially (see globalSetup documentation)
  • Build less, run more
    The current job are all installing the dependencies and most of them then install JupyterLab. Caching the dependencies packages helps but only when the cache is used and valid - it often happen on a new PR that a new upstream Python dependency is downloaded due to a newer version being available but as the job fails the cache is not updated.
    We could either move to docker stack (see Sharing Docker containers between jobs in a workflow docker/build-push-action#225)
    But as this is not a technology we are really using, we could also simply share a large artifact built by a single initial job

Additional context

@fcollonval
Copy link
Member Author

It looks also that due to the number of cache per branches, the cache is invalidated too fast for this repository:

https://github.com/jupyterlab/jupyterlab/actions/caches

@jtpio
Copy link
Member

jtpio commented Jan 19, 2023

we could also simply share a large artifact built by a single initial job

This sounds like a good first step that could maybe be implemented as an action local to the repository, and reused in other workflows.

@fcollonval
Copy link
Member Author

Among the slow job are the integration tests, Playwright documentation mentioned the ability to split them between multiple jobs using sharding tests: https://playwright.dev/docs/ci#sharding

@jtpio
Copy link
Member

jtpio commented Jan 22, 2024

For reference GitHub upgraded their runners for open source projects, which should already help a little bit:

These new machines provide up to a 25% increase in performance for most CI/CD workloads without any configuration change required.

https://github.blog/2024-01-17-github-hosted-runners-double-the-power-for-open-source/

@fcollonval fcollonval linked a pull request Mar 17, 2024 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants