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 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.
name: Test Actions
on:
push:
branches:
- main
jobs:
preTest:
runs-on: ubuntu-latest
outputs:
services: ${{ steps.services.outputs.serviceJson }}
steps:
- uses: actions/checkout@v3
- run: echo "serviceJson=$(cat .github/workflows/demo.json | jq -c)" >> "$GITHUB_OUTPUT"
id: services
shell: bash
test:
runs-on: ubuntu-latest
needs: [preTest]
services: ${{ fromJson(needs.preTest.outputs.services ) }}
steps:
- run: echo "Hello"
shell: bashI'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?
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.
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.
Shared pipelines also exist: https://docs.github.com/en/organizations/managing-organizati... and https://docs.github.com/en/enterprise-cloud@latest/repositor...
Hosting runners on K8S is similarly easy; GitHub even built a controller to help: https://docs.github.com/en/actions/concepts/runners/actions-...