(GitLab supports using its CI/CD on a non-GitLab repo just fine, but it can cause some initial confusion.)
(GitLab supports using its CI/CD on a non-GitLab repo just fine, but it can cause some initial confusion.)
Then they moved the repository replication to the paid plan (20$/month/user).
For a simple 10 person team, that's 200$ a month. Exclusively to get access to repository replication !!
I have my own runners, so there's no reason to pay for the paid plan. I just end up hacking around some replication script.
See https://medium.com/@PedroGomes/mirror-repository-to-gitlab-f...
It looks like "pull" replication is available on the $4/mo. plan, per their documentation.
It's on qemu, not that fast but it works.
> CI/CD is a part of both the open source GitLab Community Edition and the proprietary GitLab Enterprise Edition
https://about.gitlab.com/stages-devops-lifecycle/continuous-...
As I start to use more advanced features of CI/CD, I might get a better idea of how they compare. I am aware that GitHub Actions has a marketplace but I don't really want to set up my builds that way. I would rather write the steps myself, pulling in docker images and packages from package managers like npm, PyPI, and apt as needed.
They also differentiate heavily on how they work. With GitLab, if you for example want to run jobs on ephemeral KVM virtual machines, you would have an agent on host machine (or multiple of them), which would then receive a job, spawn VM, execute commands in it, and at the end terminate it.
With GitHub, you would have to spawn VMs in advance, and launch their agent in each of them. When agent dies, you will have to manually kill the VMs, and spawn a new one.
This means that there is no easy way to have VMs spawn on demand, or to spawn different VMs with different configurations depending on job label.