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.
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.