In general, the foundations upon which it was built.
In specific, off the top of my head:
- you can't group repos
- CI/CD is far behind what GitLab offers
- Review apps (though I think now you can do this on GH with other tools)
- Can't mark PRs as drafts by default in GH
- better metric tracking, easier to see a "snapshot" of where something is at on GitLab
Tbf, GH may have closed some gaps over the years but when I was bouncing between the two GH always felt a lot more rigid and further behind than GL. It did have fantastic support for open source though, and has a few unique and fun things like the `io` site stuff. Overall though if I could choose which to work in for serious projects I'll always choose GL.
I don't understand why GitLab CI is praised so much when it is the most limited and unintuitive ones of all the CI systems I've worked with.
I have hit so many issues and limitations on GitLab which is just simply possible on GitHub. Here's a few of my rants with GitLab
1. The smallest unit of action on GitLab is a whole job, on GitHub, that's a task. So all of the actions or templated files can perform a single task instead of a whole job. This granularity is incredibly useful and lets my team create a catalog of actions that our downstream teams can simply include and compose it over a variety of tools and frameworks.
2. You cannot share secrets between jobs. This was just outright ridiculous when it meant that in each new job you have to fetch an STS token even though the token from a previous job would suffice. So much repetition. When you have a template like fetching AWS credentials using OIDC, that's the only thing you can do. Hence proving point 1.
3. Multiple workflow files instead of a single `.gitlab.yml` with a scrambled mess of rules
4. Dynamic services, in GitHub it is effortless to build a matrix AND have services spun up from it. The amount of duplication this reduces is insane.
> don't understand why GitLab CI is praised so much when it is the most limited and unintuitive ones of all the CI systems I've worked with.
I'm baffled by remarks of GitLab's ICD being "unintuitive". I mean, GitLab's pipelines are made up of a set of stages, and stages are made up of a set of jobs. To put it differently, GitLab's pipelines are made up of jobs, which are grouped into stages. Does this go against your personal notion of a pipeline?
> The smallest unit of action on GitLab is a whole job
No. A job is the smallest unit of execution you can assign a runner to execute. It is used to set things like dependencies and runtime environments. Once your job sets the environment, your job can start to execute your scripts. This means a set of individual shell commands or shell scripts you provide.
> You cannot share secrets between jobs.
Yes, and only a very silly and clueless person would ever think it would be a good idea to share secrets through random runners due to exfiltration risks.
This is not a GitLab thing, mind you. You should really read this
It has a wider feature set and is just generally easier to use. When I had to set up GHA I was constantly surprised with how hard some very basic things were that were trivial with GitLab CI.
GHA was based on Azure Actions, which was never intended as a CI system nor meant to be used in a context where actions could be malicious. So it's the wrong tool for the job that had to be adapted to fit another use case, straying from its original design principles to make it work.
It's so trivial to put together any CICD pipeline that it barely registers as a skill you need to develop. All jobs run on containers you control, you specify the scripts you want to run in each job (e.g., npm test), and done. For standard pipelines you don't even bother to set precedence and fan-out/fan-in because if you set your stages as the default stages then that's already done for you.
Also nice, GitLab provides terraform providers for it's CICD infrastructure.
GitHub Actions in comparison is a god-awful mess that has only parallel in Azure YAML Pipelines, another abomination that should be used as a punishment instead of a production system.
In general, the foundations upon which it was built.
In specific, off the top of my head:
- you can't group repos
- CI/CD is far behind what GitLab offers
- Review apps (though I think now you can do this on GH with other tools)
- Can't mark PRs as drafts by default in GH
- better metric tracking, easier to see a "snapshot" of where something is at on GitLab
Tbf, GH may have closed some gaps over the years but when I was bouncing between the two GH always felt a lot more rigid and further behind than GL. It did have fantastic support for open source though, and has a few unique and fun things like the `io` site stuff. Overall though if I could choose which to work in for serious projects I'll always choose GL.
GitLab has a top of the class CICD system that is leaps and bounds over GitHub Actions. That alone makes it worth using GitLab.
I don't understand why GitLab CI is praised so much when it is the most limited and unintuitive ones of all the CI systems I've worked with.
I have hit so many issues and limitations on GitLab which is just simply possible on GitHub. Here's a few of my rants with GitLab
1. The smallest unit of action on GitLab is a whole job, on GitHub, that's a task. So all of the actions or templated files can perform a single task instead of a whole job. This granularity is incredibly useful and lets my team create a catalog of actions that our downstream teams can simply include and compose it over a variety of tools and frameworks.
2. You cannot share secrets between jobs. This was just outright ridiculous when it meant that in each new job you have to fetch an STS token even though the token from a previous job would suffice. So much repetition. When you have a template like fetching AWS credentials using OIDC, that's the only thing you can do. Hence proving point 1.
3. Multiple workflow files instead of a single `.gitlab.yml` with a scrambled mess of rules
4. Dynamic services, in GitHub it is effortless to build a matrix AND have services spun up from it. The amount of duplication this reduces is insane.
> don't understand why GitLab CI is praised so much when it is the most limited and unintuitive ones of all the CI systems I've worked with.
I'm baffled by remarks of GitLab's ICD being "unintuitive". I mean, GitLab's pipelines are made up of a set of stages, and stages are made up of a set of jobs. To put it differently, GitLab's pipelines are made up of jobs, which are grouped into stages. Does this go against your personal notion of a pipeline?
> The smallest unit of action on GitLab is a whole job
No. A job is the smallest unit of execution you can assign a runner to execute. It is used to set things like dependencies and runtime environments. Once your job sets the environment, your job can start to execute your scripts. This means a set of individual shell commands or shell scripts you provide.
> You cannot share secrets between jobs.
Yes, and only a very silly and clueless person would ever think it would be a good idea to share secrets through random runners due to exfiltration risks.
This is not a GitLab thing, mind you. You should really read this
https://secure-pipelines.com/ci-cd-security/gitlab-ci-cd-sec...
> Multiple workflow files instead of a single `.gitlab.yml`
Now I wonder if you're just trolling.
> Dynamic services,
Now this is just silly. Did you even bothered to learn how GitLab handles this?
https://docs.gitlab.com/ci/yaml/matrix_expressions/
What’s so much better about it? I use both and I don’t see significant differences, but I’m happy to be enlightened.
It has a wider feature set and is just generally easier to use. When I had to set up GHA I was constantly surprised with how hard some very basic things were that were trivial with GitLab CI.
GHA was based on Azure Actions, which was never intended as a CI system nor meant to be used in a context where actions could be malicious. So it's the wrong tool for the job that had to be adapted to fit another use case, straying from its original design principles to make it work.
1 reply →
> What’s so much better about it?
It's so trivial to put together any CICD pipeline that it barely registers as a skill you need to develop. All jobs run on containers you control, you specify the scripts you want to run in each job (e.g., npm test), and done. For standard pipelines you don't even bother to set precedence and fan-out/fan-in because if you set your stages as the default stages then that's already done for you.
Also nice, GitLab provides terraform providers for it's CICD infrastructure.
GitHub Actions in comparison is a god-awful mess that has only parallel in Azure YAML Pipelines, another abomination that should be used as a punishment instead of a production system.
Parent child pipelines
Shared pipelines across multiple projects
rules: have far more flexibility than githubs if:
GitLab is very easy to fan out CI/CD runners on your own k8s infra.
3 replies →