New tool for managing self hosted GitHub runners, https://cloudbase.it/manage-your-own-github-runners-using-garm/
Garm is a self-hosted, automated system that maintains pools of GitHub runners on potentially any IaaS which has an API that will allow us to create compute resources.
We recently moved to a monorepo in gitlab. I setup the pipeline to run jobs based on what files have changed using
rules:changes. Unfortunately I missed this gem in the troubleshooting section until after the changes were released:
The changes rule always evaluates to true when pushing a new branch or a new tag to GitLab. So now every new branch is building and deploying all apps instead of just the one(s) with changes. Anyone run into this? Any recommendations on fixes?
I’m hoping to avoid adding some sort of check to all jobs as to whether or not they should run and exit early if not.
Looks like the way to go is dynamic pipelines. https://infinitelambda.com/post/dynamic-pipeline-generation-gitlab/
Dynamic pipeline generation on GitLab: see how to create a well-organised yaml file with less effort and make your life easier with automation.
Can’t you just add
- when:never to the bottom of the rules section to stop any other non specified rules
Since the changes rule always evaluates to true when pushing a new branch or tag, that wouldn’t help.
@bradym interesting .. as I am seeing a host of other issues with a monorepo and we are thinking to separate at least the infrastructure as a code out of the repo
I’m not at all a fan of using a monorepo, it makes everything more difficult when it comes to CI.