CI: Use buildjet to get faster builds #5393
Conversation
|
Every push you do on your repo is completely clogging the build pipeline for one hour because of the duplicated builds. Just using some a different runner is not going to improve that... We should (temporally) merge #5377 to get at least rid of the duplicated workflows for now. I want to see if there is a different working approach but the current situation is unacceptable. |
|
Also as mentioned in the other ticket I don't think this will be of any major help since most of our bottlenecks are not with the build but anything else and those are almost all single-threaded in nature. Also build times are quite erratic on GitHub in general so to do a proper comparison you need to do several builds and also make sure the caches are actually filled to make sure it will actually help. I had major issues in the past to actually confirming that some improvements I made were actual improvements. |
|
I have the feeling that we have too few runners. It should be possible to run to jobs in parallell. |
|
Right now this job has this statistics: So only 8 checks are executed in parallell. There are 100 checks that are not running right now they are waiting. |
We run 20 jobs in parallel which is a lot. Since we have 60+ jobs - many of those because we support lots of build systems, EOL version and other stuff we should no longer support at all. I see almost 15 jobs we could just delete if we decide to drop support for outdated or EOL stuff. |
That is since there are other builds running |
so.. it would be faster if I stopped creating branches in the root repo? hmm.. thanks I had not thought of that. |
I feel this is too little. If we can get more I would be interested to know how.. even if there are costs.. |
That should work. I have no idea why no other repos have that issue I did not yet have time to investigate fruther. I wanted to run some experiments but that doesn't work if the CI is overloaded. 🫤 |
It's enough - believe me. Adding more runner won't help at all if you have staggered builds or one of the longer running jobs is triggered last (it seems there's no way to specify a priority). Please take a look at the list I posted here for things that will help way more than just throwing money at it: #5377 (comment) |
I want that all jobs are triggered directly. As you say.. in particular the longest running jobs must be triggered immediately. |
Well, if you have lots of money to spend/waste that can be achieved but not for much gain. If you would set up a self-hosted runner that would be able to do that you need a Xeon or Epyc CPU with 64+ threads - those usually set you back a few thousand dollars just for the processor...using multiple smaller system might not be much cheaper - maybe even more expensive. |
I don't have infinite money.. but if we for instance could spend something like $100 per month to get a substantial improvement then I would like to know it.. preferably with some cloud solution rather than buying our own hardware.. |
It won't be substantial in total. I recently had to get a new machine and the compilation speed up was huge but the files which compiled slow are still compiling slow. It was mainly because of the increased core count which help to chew through the smaller files. But everything else has not gotten much faster. You need to do optimizations. |
|
Sorry for being so harsh but that's how I get when (major) changes just get dropped on top of it and there's still other ways to possibly reach the same goal. And even more so if those changes might infer with working on the other approaches. Hopefully I will be able to file tickets for all my ideas/experiments in the next few days. I really like it though that you are willing to back it up with more resources. |
No description provided.