-
Notifications
You must be signed in to change notification settings - Fork 149
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
Continuous Integration Performance and Robustness Brainstorming #311
Comments
Migrate to GitHub ActionsIt seems to be where things are going, and 2x simultaneous jobs than Azure Pipelines. |
Investigate mamba
Using |
Investigate conda-lockInstead of even solving the environments in CI, we could generate them quickly, offline, and check them into the ci subfolder. Stacks with |
Revisit cachingBeing able to cache:
...in roughly that order, would knock some minutes off all of the runs, but particularly on windows which seems to have really bad IO. Github Actions and Azure both have more advanced (but of course, incompatible) caching actions. They all work best if we have things checked in that get hashed. The entropy on the built lab is pretty challenging to describe. |
Investigate dodo
|
Some test cases fail on timeouts (especially on Windows):
or:
or:
yet, they usually work out in the final attempt. The 5 seconds timeout could probably be extended (10s?). |
Don't run jest tests on windowsThe jest tests take 3 minutes on windows, and don't really provide additional information vs the linux/osx runs (other than node not working great on windows, which is known) since it's all make-believe DOM. I move we just drop them from all the windows runs on azure. |
Playing around with gtihub actions.. is there a reason why we use conda rather than miniconda? |
Or, do we? Honestly cannot see when it is getting installed... |
Miniconda is the _distribution_, while conda is the _tool_. Both azure and
GitHub actions have _an_ version preinstalled. I'm happy to take a look at
this as well, having recently been using actions more.
|
Obviously I meant anaconda ;) Trying to use https://github.com/conda-incubator/setup-miniconda (seems to support mamba in a way?) at the moment after previously trying setup-conda and having a brief look at setup-mamba (which does not seem to support Win) |
Cache built lab staticRebuilding JupyterLab with all the extensions on Windows is important, at least until 3.0. However, it does take a rather long amount of time, in the 3-4 minute neighborhood. I have a hunch after we run all of our |
Run robot tests in parallelpabot can run tests in parallel. I think our tests are sufficiently self-contained (minus things like the jedi/tectonic caches) that we could run them in parallel, so it might be a one-line change (e.g. The browser tests are the reason we're doing half this stuff, but they also contribute over half of the duration, by themselves. A lot of that is waiting around for the browser to load/do stuff, which might not actually be that taxing on the poor little processor (especially windows). However, given an anecdotal win/py37 runtime of around 27 minutes, even getting a 25% reduction in duration would be beneficial. Additionally, if this allowed local tests to run even faster, it would reduce the pain of developing/maintaining/refactoring robot tests, as well. Update: this is now available on conda-forge |
Elevator Pitch
Let's gather some ideas for how we might improve the value we're getting from CI.
Motivation
CI is not really that broken, but it's pretty slow. There might be some other tools and services we can look into which wouldn't require altering the code that much, so can be done in parallel, and incrementally, while feature work is on-going.
Design Ideas
Post/emote ideas below.
The text was updated successfully, but these errors were encountered: