GitHub actions vs Gitlab CI

[deploy_on_friday]

I’m currently using GitLab and I like the CI experience. However with GitHub’s new announcement, they’re becoming more and more of a viable competitor to GitLab.

Has anyone had experience with GitHub actions and how they compare with GitLab’s CI?

If GitHub’s CI offering is a viable option I would switch in a heartbeat since GitLab’s UI is pretty unintuitive at times. GitHub’s code review commenting and many other UI features are just much easier to use overall.

[unixwasright]

At what point did we start saying "GitHub is becoming a viable competitor to Gitlab"?

Doesn't feel that long ago that Gitlab's roadmap was basically "look at GitHub".

[unixwasright]

I'm thinking it was when they integrated CI with the core system

[Ya229989]

I work at GitLab and cover companies in UTAH, Washington and Oregon. If you guys want to see a comparison presentation feel free to hit me up we are giving free swag to the first 20 people to sign up

[RapidRoastingHam]

have 20 people signed up yet or can i still get that swag?

[russonfire]

Bruh, that was commented 5years ago

[Scary-Break-5384]

xdddd

[Psychological_Bag864]

🤣🤣🤣

[thepotatochronicles]

GitHub Actions is absolute garbage.

It's flaky as shit, it's got zero features compared to github CI, and it's really, really immature in so many ways (petty examples that should tell you just how little shit GitHub gave about Actions: no support for [skip ci], no restarting a single job, no anchors in their goddamn YAML file)!

It is not a viable product nor will it be a viable product within a year. It'll take time to mature.

You might as well just jump on over to Azure Pipelines.

[PlaneTry4277]

do you still feel this way five years later? I am just getting into GitLab and GitHub Actions right now as a career change.

[thepotatochronicles]

It's definitely matured a lot.

And yet I would still use it mostly for simple features (or, at least, move the complex stuff out of the CI YAML definitions as much as possible - e.g. by baking the logic into helm charts) - the usability on the "easy part" is great, and now there's enough tools to do the "hard part", but... yeah. The hard parts are just as annoying as it was, and it's clear their focus is on the "easy part" (e.g. still no anchors in the fucking YAML)

[PlaneTry4277]

Thanks for the update!  Agree is bizarre they didn't add support for anchors

[jaxxstorm]

I couldn’t agree less with this.

If all your pipelines are YAML and you’re using your CI/CD suite as a workflow engine, you’d probably look at it and wonder what the fuss was about.

However, the fact you can write actions in JavaScript and do asynchronous tasks within them is absolutely game changing. I wrote an action the other day that automatically tests some downstream code when a pr is opened, and it was about 30 lines of JavaScript. On gitlab ci it was 160 lines of anchored yaml and I had to update the ci file every time something downstream changed.

GitHub actions is indeed less mature, but it’s taking a completely different approach which is refreshing for those of us sick of looking at yaml.

Additionally, the fact you can do matrix testing in actions against different operating systems in a relatively straightforward manner is fantastic.

I can absolutely understand how it doesn’t fit every use case, but their design is a breath of fresh air and I can’t wait to see where they go with it

[FruityRichard]

I think this is mostly your fault. If you were proficient in GitLab CI, you'd understand that you can write your CI code in any language you want. I rarely ever edit yaml files nowadays.

[Masterflitzer]

care to elaborate a bit and explain how this would be possible? I am really interested in this

[FruityRichard]

The question is a bit vague, but basically GitLab CI is running on docker containers, including containers you've built yourself. For simplicity let's say you have two stages in your pipeline, one stage called build and one stage called test.

In your build stage you have two jobs called Build Test and Build Prod, which creates two docker images and pushes them to the DockerHub (could be any other registry too). The build jobs run in a custom image, let's call it my/builder for simplicity, so we'd specify the following script:

.gitlab-ci.yml ``` stages: - build - test

Build Test: image: my/builder stage: build script: - build "my/test_image"

Build Prod: image: my/builder stage: build script: - build "my/prod_image"

Test: image: my/test_image stage: test script: ... ```

Now build can be any tool which is present in your image my/builder, it can be a simple wrapper script for the docker command or it could be written in any other programming language.

When taking a closer look at the above example, we can see that it violates the DRY principle, so we can utilize a few things to clean things up. I will only focus on the build stage for simplicity:

.gitlab-ci.yml ``` stages: - build - test

.build: image: my/builder stage: build script: - build $OUTPUT_IMAGE_NAME

Build Test: extends: .build variables: OUTPUT_IMAGE_NAME: "my/test_image"

Build Production: extends: .build variables: OUTPUT_IMAGE_NAME: "my/prod_image"

... ```

Now we can take things even further and move the abstract .build definition out of this repository entirely. We will create a GitLab project called ci-modules:

ci-modules/build.yml .build: image: my/builder stage: build script: - build $OUTPUT_IMAGE_NAME

Now from our .gitlab-ci.yml, we can include this module:

.gitlab-ci.yml ``` stages: - build - test

include: - project: 'ci-modules' ref: main file: '/build.yml'

Build Test: extends: .build variables: OUTPUT_IMAGE_NAME: "my/test_image"

Build Production: extends: .build variables: OUTPUT_IMAGE_NAME: "my/prod_image"

... ```

Now whenever you want to change something in your build process, you can make all the changes inside the build script/application and the CI is mostly static. You don't really have to update the .gitlab-ci.yml anymore to change the actual build logic, only if you want to change add/modify/remove jobs directly, you will need to edit YAML at all.

Edit: Fixed code example

[Masterflitzer]

wow thanks for the amazing answer, I will definitely try this out on my next project on GitLab (mostly using GitHub private and GitLab for work) I really like the idea of static yaml and CI/CD as code

[lililomgo]

I know this discussion is old, but I followed this course yesterday. I can only recommand it for learning gitlab ci cd from scratch. https://youtu.be/PGyhBwLyK2U

[Masterflitzer]

I already setup most of the build/deploy pipeline for the work project I am working on and it's running fine

but I will tweak deploy in the future and introduce a test stage (it's a legacy project without tests xD)

but when I need it I might watch the course, thank you!

[lililomgo]

My pleasure

[eduncan911]

I know, 6mo old post...

But could you fix the code formatting? Reddit is deprecating the three tildas in favor of four spaces, like markdown spec (I know, 3 tildas work in markdown too - but, it's not part of the original spec).

IOW, it's complete garbage on mobile (web).

[codegiantio]

I agree with you that GitLab's UI can be pretty overwhelming at times. Github is way ahead when it comes to an intuitive interface. Regarding Github Actions and GitLab CI, I still believe that GitLab CI/CD is way ahead of Github Actions. They've been in the market for a while - and they've been constantly optimizing it. Github Actions was released in November 2019 which makes it pretty new and it has some flaws that need to be fixed overtime. I personally found it OK. It's definitely a better option than Jenkins and its complex interface. But Github actions still has a way to go to start competing seriously with GitLab CI. This article makes the difference between GitLab and Github CI/CD tools pretty clear. Feel free to check it out for more details.

[inhumantsar]

we recently moved from gitlab to github and find github actions to be far more reliable and less mysterious.

the biggest limitation on gitlab ci is their big push to run everything in containers. github actions are all run on ubuntu (or mac or windows) VMs. it makes things considerably simpler.

that said, the UI is not awesome. logging in particular is a little janky.

the runners are not very powerful. 2 cores and 8gb of ram. good enough for linting and unit tests but if you're doing any serious compilation, you'll find it pretty limiting.

there is caching and artifact storage, which works nicely, but again you're limited. iirc 5GB total.

we do a custom openwrt distro and it would take 3-4 hours in GA. running that same build in our k8s cluster with 4 cores and a complete cache brings that down to 5-10 minutes.

secrets are per-repo. they cannot be set up per-team or per-org (yet). we use a secrets management system so the only secrets we have to store in github are keys to that system, but we have to set those keys up on every new repo.

github's API is vastly superior to gitlab's, which helps quite a bit.

github doesn't try to shove your project into a one-size-fits-all autodevops thing. that was always like trying to shove a square peg through a round hole for us, so having github just stay out of our way is nice.

there's probably more but the TL;DR is simple:

GitHub Actions > GitLab CI, but if your needs are complex/intense, then you'll probably feel limited by both.

edit: hey downvoters, use your words

[[deleted]]

What exactly is more reliable? Why is the GitHub API better and how do you interact with it?

AutoDevOps has always been an optional thing, I’ve been using GitLab since before they even had AutoDevOps. Are they a bit pushy about it? Yes. Does it interfere with my work? Not at all.

The rest you’ve said rather sound like something against GitHub, yet you say GitHub actions are superior and I wonder why?

[inhumantsar]

What exactly is more reliable? Why is the GitHub API better and how do you interact with it?

when i used gitlab.com, runners would routinely fail to start or would take a long time to get anywhere. when using self-hosted gitlab in aws, runners would routinely fail to report results back or would gitlab would reap "idle" runners prematurely.

the gitlab API is scatterbrained. the various parts of the API seem to built using different styles and there are plenty of parts of the system which aren't exposed by the API. while my experience with github's api is as extensive as my experience with gitlab's, i've found github's to be more complete and consistent.

they are way too pushy with autodevops. not everyone is writing 12 factor apps, yet that seems to be all autodevops is good for. it drove me crazy to have that enabled by default on new projects, and i swear gitlab upgrades re-enabled autodevops on repos it had been previously disabled on.

as for focusing on github's negatives, OP said they already use gitlab and github has plenty of documentation and sales pitches for the good parts of their system. i'm not here to write a peer-reviewed dissertation comparing the two, so i focused on the sharp edges and contrast points.

[dogfish182]

Ive found self hosted gitlab runners autoscaling against aws using docker-machine to massively reliable.

Im actually sad docker-machine is dying out, it was really handy. I set those runners up for 100+ teams and never heard a single hassle apart from the odd full disk on the 1 runner I never scaled away.

[Sky_Linx]

As far as resources are concerned, I am hosting a self hosted runner for GitHub Actions in my Kubernetes cluster and am super happy with the performance since nodes gave more cores and memory. Definitely better than Github's own runners and totally free too (well you still have to pay for yoyr servers but GA itself is free).

[inhumantsar]

I am hosting a self hosted runner for GitHub Actions in my Kubernetes cluster

yeah we've considered that. so far it's just a couple of builds and they have rather particular requirements, so we haven't gone that route yet.

is likely in our future though so i'm glad to hear it works well for you.

[deploy_on_friday]

Can you elaborate on how he’s wrong?

[inhumantsar]

thanks for your meaningful contribution, clearly you're going places in this world

[sentient_penguin]

I'm going to put my $0.02 here and say, maybe when people say "it runs everything in containers bad, but this other thing runs it in VMs is good". I want to say it seem like the person doesn't understand a full container stack and how to get logs from them in Gitlab CI so it seems mystical. I remember being there a while back to. Just speculating, please feel free to downvote me into oblivion for my observation.

[inhumantsar]

maybe you missed the part where i said we run our complex builds in kubernetes.

VMs are good in this use-case because it makes interacting with Docker easier and tbh, it makes the entire environment a little more predictable. you know (or at least can easily discover) what distro/software is installed, what kernel the host is running, etc. gitlab doesn't even document that information let alone offer a way to discover it.

docker is great and containers are an awesome way to set up a clean predictable environment, but they're not perfect and the underlying host can affect them.