Replies: 4 comments 8 replies
-
|
I think we also need to look into minimizing (however possible without compromising test coverage) the amount of builds running. |
Beta Was this translation helpful? Give feedback.
-
|
How do we feel about disabling all automatic Github-hosted workflows for Pull Requests and delegate it to maintainers to manually decide which workflows to run and when for a given PR? The |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if our main issue is that we have many long running |
Beta Was this translation helpful? Give feedback.
-
|
Well I was the one who set up the We also have way too many jobs in general. Aside from removing jobs you can also try spreading out the load between ARM and x86 machines if possible, some stuff like those cross compiles or webgpu runs can probably be done on ARM. There's also the new ubuntu-slim machine which they hopefully have more of and which we can use for simple jobs that only need 1 core and 5 gigs of memory. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Overview
With the current trend of the Github Actions runners becoming increasing slower and slower, we are close to not having a useable CI pipeline. Opening this discussion to discuss what we can do about this.
Queue time for last 6 months
TODOs
riscvworkflows only on themasterbranch and not in PRs.ymlfilesccache-action: ci : discuss optimization strategies #20446 (reply in thread)Upcoming self-hosted runners
One of the best way to minimize the queue times is to move the workflows to self-hosted runners that are dedicated to running ggml workflows. This requires provisioning and hosting hardware.
Beta Was this translation helpful? Give feedback.
All reactions