3 ms·
I love gitlab but I run into two issues constantly: 1. Gitlab CI with DinD kills the docker cache on every build. For a large monorepo this is a huge pain. Rea
by gravypod 6y ago
I love gitlab but I run into two issues constantly:
1. Gitlab CI with DinD kills the docker cache on every build. For a large monorepo this is a huge pain. Really needs to be addressed with some host volume mount of the docker daemon layer cache per concurrent job.
2. No say to specify CPU/disk/memory usage of a CI stage. I have a large number of builds that need ~512mb of ram per build and another build that needs 4GB of ram. Because of this I need to make sure every instance of the runner has exactly 4GB of ram available. This is a large waste of resources.
Gitlab is a fantastic product and I'm super happy for migrating multiple companies to it and that they keep innovating.
- mcintyre1994 6y agoOn your second point, you can achieve this with tags. See here: https://docs.gitlab.com/ee/ci/yaml/#configuration-parameters https://docs.gitlab.com/ee/ci/yaml/#configuration-parameters and https://docs.gitlab.com/ee/ci/runners/#using-tags https://docs.gitlab.com/ee/ci/runners/#using-tags On the runner side you can tell it which tags to accept, and on the .gitlab-ci.yml side you can tag your jobs. We mainly use this to make most jobs run on AWS EC2 spot instances, but a few use on-demand instead. We also use it to give a couple of jobs a larger instance size.
- gravypod 6y agoCan you do that within the same repo? I mainly work in a large monorepo.
- mcintyre1994 6y agoYep - I use a monorepo too. You just set tags on your runners, and tags on your CI jobs, and Gitlab’s scheduler will assign the jobs to correct runners for you. It’s worked perfectly for us.