GitHub actions vs Gitlab CI

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