#release-engineering (2022-05)
All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.
CI/CD Discussions
Archive: https://archive.sweetops.com/release-engineering/
2022-05-17
New tool for managing self hosted GitHub runners, https://cloudbase.it/manage-your-own-github-runners-using-garm/
2022-05-18
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/
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.
@bradym You can still separate these repos and develop separately while have a monolithic view with google repo tools or something like that.
Link to the tool: https://gerrit.googlesource.com/git-repo/