Ive never used githubs CI/CD, but gitlab has quite a large ecosystem for its CI/CD.
Seems to me like you could use gitlab as a one-stop-shop to host everything from your code to your artifacts and containers, if you are willing to pay for those fancy features
Free is able to just do basic CI/CD for like 250 minutes a month, or unlimited via your own runners/build servers, thats about it
GitHub’s actions are so good once it clicks and you understand them. On GitLab, you start from a docker image, so it’s harder to setup some things but easier for others. If you are very good at docker and don’t mind making your own images just for CI purposes, then go ahead.
Ideally, you should just try them both. You can mirror a project between the two and setup the CI at both places.
On GitLab, you start from a docker image, so it’s harder to setup some things but easier for others. If you are very good at docker and don’t mind making your own images just for CI purposes, then go ahead.
I think I’d probably consider myself at/near expert-level with Docker, but CI/CD runners instanced in containers just doesn’t work for some of our workloads.
As an example, some of our projects have a bunch of Docker images that get built via their own Dockerfiles in the repo, are ran and discarded during the workflow, and each one is modifying the checked-out source tree in some fashion (NPM stuff, composer, whatever, etc), and then a final prod Docker image is built and tested from that source repo tree that has been modified by the Docker containers built/ran/discarded during the workflow. So in Gitlab, it sounds like we’d be running Docker in Docker for some projects.
You ever ran Docker in Docker? It’s temperamental at the very best and there are a thousand gotchas associated with it, not to mention having to worry about how many variable scopes deep you are and keeping track of that, how to properly bind mount volumes into the nested Docker containers because the method and paths will vary depending on how nested you are, etc. It’s just an absolute nightmare to deal with all-around in that context.
I’ll see if we have some projects I can try out on it, but the majority of ours are like what I described above.
I dont post my code to github because I would rather use gitlab
We are not the same
I dont post my code to gitlab because I would rather use codeberg
We are not the same
I want to start moving stuff into Gitlab, but Github Actions is just too good. Is the CI/CD stuff in Gitlab comparable?
Ive never used githubs CI/CD, but gitlab has quite a large ecosystem for its CI/CD.
Seems to me like you could use gitlab as a one-stop-shop to host everything from your code to your artifacts and containers, if you are willing to pay for those fancy features
Free is able to just do basic CI/CD for like 250 minutes a month, or unlimited via your own runners/build servers, thats about it
GitHub’s actions are so good once it clicks and you understand them. On GitLab, you start from a docker image, so it’s harder to setup some things but easier for others. If you are very good at docker and don’t mind making your own images just for CI purposes, then go ahead.
Ideally, you should just try them both. You can mirror a project between the two and setup the CI at both places.
I think I’d probably consider myself at/near expert-level with Docker, but CI/CD runners instanced in containers just doesn’t work for some of our workloads.
As an example, some of our projects have a bunch of Docker images that get built via their own Dockerfiles in the repo, are ran and discarded during the workflow, and each one is modifying the checked-out source tree in some fashion (NPM stuff, composer, whatever, etc), and then a final prod Docker image is built and tested from that source repo tree that has been modified by the Docker containers built/ran/discarded during the workflow. So in Gitlab, it sounds like we’d be running Docker in Docker for some projects.
You ever ran Docker in Docker? It’s temperamental at the very best and there are a thousand gotchas associated with it, not to mention having to worry about how many variable scopes deep you are and keeping track of that, how to properly bind mount volumes into the nested Docker containers because the method and paths will vary depending on how nested you are, etc. It’s just an absolute nightmare to deal with all-around in that context.
I’ll see if we have some projects I can try out on it, but the majority of ours are like what I described above.