7 ms·

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to m

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem with losing slightly there is that the advantage compounds; if developers find it easy to make and share, then they make and share which makes more people make and share and generates tons of value for a platform. It may not be safe, but being able to: - uses: some-developer/some-repo@some-branch Is absolutely amazing. Everything else (generally) GitLab has, and (likely) did first, but the social viral stuff GitHub just gets right in a different way than GitLab does. No one would accuse GitLab of being a "copy" in recent memory like they did in the bad old days, but IMHO they need to just copy the shit out of when GitHub gets social things (like this) right.

capableweb 3y ago
> GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece As someone who only used GitLabs CI briefly when it initially launched, what hard parts did they innovate on exactly? As far as I could tell, it's a run-of-the-mill CI/CD platform, for better or worse, but nothing I'd call "innovative". But again, maybe since the first time I tried it when it launched, it has changed, and I missed something really cool they did.
- starttoaster 3y ago
  Innovative is a strong word, but they always had the best support for a variety of deployment archetypes, including baremetal, kubernetes, docker, docker+machine (autoscales VMs in a public cloud to run many Docker executor runners.) They also had JWT authentication support built into GitLab before GitHub even had a CI offering at all. The GitLab kubernetes agent makes their CI/build tool more like a CD tool for organizations that primarily deploy to kubernetes clusters, which is fairly unique for a CI tool to act as a CD tool, though with scripts people often just make the CI tools do deployments anyway. My experience is limited to GitHub Actions, GitLab CI, and Jenkins. I've never been in an organization that managed to crack the code on running Jenkins in a sane way (always a poorly maintained, bloated mess of plugins, unfortunately) so I can't say I count Jenkins as a contender in this conversation. One could argue it's unfair to discount Jenkins because of organizations that manage it poorly, but there's something to be said about a tool that is so easy to accidentally run in an unmaintainable way. I also have some limited experience with Drone and Circle, but not enough to talk about them confidently.
- hardwaresofton 3y ago
  Off the top of my head: - Bring your own runner is easiest/most robust - environment deploys and management - tons of deployment integrations - DevSecOps features - Built in support ticket handling - Free container & package registry For most of these I’m pretty sure gitlab had them built into the platform (and free!) first
- ak217 3y ago
  They integrated in-repo configuration, self-hosted runners, composable workflow definitions, a robust API, and container building and registries for the first time in a CI tool. Of course GitHub came and blew that out of the water with a composable social actions ecosystem. Which was brilliant and remains the killer feature that puts GitHub far beyond reach of other CI platforms, especially now that they've improved in-repo composability a few months ago.
  - capableweb 3y ago
    > They integrated in-repo configuration, self-hosted runners, composable workflow definitions, a robust API, and container building and registries for the first time in a CI tool. Out of those, I think only "composable workflow definitions" would be one of the features that other CI platforms didn't have, before GitLab even existed as a project. You might want to re-read the history and features of build platforms before GitLab.
    - ak217 3y ago
      I'm very familiar with the history of CI platforms before GitLab, having used Hudson, Jenkins, Circle, Travis, Appveyor, Codebuild, and a whole bunch of other platforms extensively. While some of them had these features, none of them had all of the features, few of them meaningfully integrated the features together, and most of them provided the features in a very half-assed and unreliable way.
dijksterhuis 3y ago
It’s possible to do ‘uses’ on GitLab, but there’s a few extras needed admittedly (branch name and path to file) include: https://gitlab.com/awesome-project/raw/main/.before-script-template.yml https://docs.gitlab.com/ee/ci/yaml/includes.html#include-a-single-configuration-file https://docs.gitlab.com/ee/ci/yaml/includes.html#include-a-s... But I agree, the social virality is what makes GitHub Actions what it is. I used to only visit a GL project when I needed to look through Nvidia cuda container builds… everything else I needed was on GH :shrugs:
trilbyglens 3y ago
Currently working on a gitlab api thing for work, and I gotta say their API us a complete joke. GitHub runs laps around them in this area. Gitlab is actually worse than bitbucket, believe it or not.
tomjakubowski 3y ago
Travis and Circle CI predated Gitlab, with YAML-configured workflows checked in to the repository and the ability to use custom images. GitlabCI's innovation was integration: making it a feature of repo hosting.
- Ayesh 3y ago
  I moved from Jenkins to Travis several years ago, and Travis's UI and configuration was such a fresh breath. Back then, pretty much _every_ OS project used it because of their generous offerings for open source projects. I agree with this comment that, and from my own experience living through the transitions, Travis CI made a massive leap leveling up the modern CI we have today.
- hardwaresofton 3y ago
  Yeah I didn’t say they innovated CI/CD — I said they innovated CI/CD as a platform-native offering!
pharmakom 3y ago
I find GitHub Actions incredibly counter-intuitive, personally.
- dzhiurgis 3y ago
  It’s the confusion between actions(basically third party plugins) and workflows(the ci that you are building for yourself) that got me.
  - ambicapter 3y ago
    Thank you for finally explaining this to me (have had to deal with github ci off and on for months now).
  - NameError 3y ago
    I think it was a mistake for Github to name the whole product "Actions" and then re-use the same word for a specific component within system. It's really natural to say something like "we need a push action for this repo" when it might be more correct to say "a push workflow"
    - voytec 3y ago
      > I think it was a mistake for Github to name the whole product "Actions" and then re-use the same word for a specific component within system. You're right: - product is called GitHub Actions - your workflow (consisting of jobs and steps) is a workflow - 3rd party workflow included in yours is an action, not workflow though - I more often hear engineers refer to workflows as actions But there are more annoying decisions - (org-wide) required workflows being recently deprecated - the feature was buggy (ie used alongside org-wide branch rules) - but could have been fixed, not deprecated - some kind of "marketplace" (with reviews, developers trust levels etc) for modular/pluggable actions (workflows) would be welcome; currently it's a "1st solution fitting the problem used" mess with little to no standarisation - I find the necessity to write a step cloning the repo from which a workflow is running ridiculous - it should be at most a single configuration line somewhere at the top of a workflow
chologrande 3y ago
How is Gitlab CI materially different from the jenkins model? I find that the only difference is that it's YAML - so even harder to debug, and maintains the same model where you must re run an entire pipeline every commit to test functionality.
- robertlagrant 3y ago
  You can run locally first to test functionality : - )
  - chologrande 3y ago
    oh that's nice I didn't know that! Still a stickler on yaml for code though
  - k_roy 3y ago
    how dare you suggest something so pedestrian.
- hardwaresofton 3y ago
  Yeah YAML isn’t ideal, but I personally found jenkins to be terrible to configure, not super well documented, missing features compared to an installation of gitlab (ex built in registry). Also the ability to rerun, target, and influence builds themselves is better on GitLab as well I think.
codethief 3y ago
> Gitlab CI is still the best CI in the game IMO, Oh god, if this is the best CI in the game, I don't want to be part of this game anymore. I work with (as in write pipeline code for) Gitlab CI almost every day and it's absolutely horrible. Not only does YAML lack any type safety whatsoever, but every day I run into yet another open ticket in the Gitlab issue tracker because using a declarative (YAML-based) approach (as opposed to an imperative one) essentially means that the Gitlab devs need to think of every possible use case beforehand, so as to be able to define a declaration & write an implementation for it. Clearly this is impossible, so now I'm banging my head against a wall on the daily.
- thiht 3y ago
  That’s not my experience at all. You do know you can run arbitrary shell scripts, and that means they don’t need to think of every possible use case? If your CI process is so complex that YAML + arbitrary code doesn’t work, you might want to get that checked, it’s not normal
  - codethief 3y ago
    Random example: I want to define a setup job to build & push a base Docker image to our container registry. I then want to use this image as IMAGE in all subsequent jobs. This is impossible because the IMAGE field in YAML cannot be dynamic (determined at runtime) but I'd like to version/tag my image using the $CI_COMMIT_SHA.
    - nijave 3y ago
      Can't you use build time variables for this? https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job https://docs.gitlab.com/ee/ci/variables/#pass-an-environment...
      - codethief 3y ago
        I tried this but it didn't work.
j1elo 3y ago
I'm in the apparently small group of people who ignores 90% of the made & shared features, and push back against making internal ops to depend too much to any particular CI system. We know how to build, package, and release our software, and at work I firmly support that we write those operations as standalone scripts that in principle could even run in the developer's machine itself. Moving them to CI is just changing the machine that will run the scripts, and that's where I draw the line of how much coupling to accept with any given runner: run scripts, inject secrets, and maybe accumulate artifacts between jobs. There are a myriad of things done with Actions, such as preparing NPM, or running Docker containers. I see no point in them, you should be able to manually run the same commands, one by one, locally on a VM or empty Docker container, so at that point why not write them as a script. Use CI as a dumb shell runner. Getting to depend on all those small Actions saves 5 minutes today, only to make migrations immensely painful tomorrow.
- wombatpm 3y ago
  Especially if you have to run and deploy on your own servers. Not everything can be in the cloud.
- gonzo41 3y ago
  I agree with this, I recently had a pretty long network issue with our CI system and for the most part we just reran scripts or converted ci yml into scripts. I like CI for secrets management, scrpted pipelines and deploying. And having one button do do all of that. But all the extra junk people do with it seems like another thing to have break.
- hardwaresofton 3y ago
  I definitely agree with and do this — it only falls apart when CI environment stuff interferes with file locations and other external state. That said it is nice (if the scripts are simple) to do things like machine set up very easily.
- physicsguy 3y ago
  Same. I've also had to do things like migrate CI when a company was acquired, from Travis to Circle and Circle to GitLab in the past. It's very painful to do this if you've leaned into everything the CI service offers.
jakjak123 3y ago
Very good summary. I think both Gitlab CI and Github Actions are very good, but I think gitlab ci is more practical because of how easy it is to build custom advanced pipelines vs the great re-use of github actions.
DanielHB 3y ago
In my own project we actively cut down on external CI deps (non-official github actions) as much as possible, it seems incredible unsafe When we do use an external dep (like in two places for our massive project) we pin it to a specific GIT sha that we manually curated to not contain anything weird
Kelkonosemmel 3y ago
I love GitHub actions and think gitlab is okay. I found actions easier to use

capableweb 3y ago

> GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece As someone who only used GitLabs CI briefly when it initially launched, what hard parts did they innovate on exactly? As far as I could tell, it's a run-of-the-mill CI/CD platform, for better or worse, but nothing I'd call "innovative". But again, maybe since the first time I tried it when it launched, it has changed, and I missed something really cool they did.

starttoaster 3y ago
Innovative is a strong word, but they always had the best support for a variety of deployment archetypes, including baremetal, kubernetes, docker, docker+machine (autoscales VMs in a public cloud to run many Docker executor runners.) They also had JWT authentication support built into GitLab before GitHub even had a CI offering at all. The GitLab kubernetes agent makes their CI/build tool more like a CD tool for organizations that primarily deploy to kubernetes clusters, which is fairly unique for a CI tool to act as a CD tool, though with scripts people often just make the CI tools do deployments anyway. My experience is limited to GitHub Actions, GitLab CI, and Jenkins. I've never been in an organization that managed to crack the code on running Jenkins in a sane way (always a poorly maintained, bloated mess of plugins, unfortunately) so I can't say I count Jenkins as a contender in this conversation. One could argue it's unfair to discount Jenkins because of organizations that manage it poorly, but there's something to be said about a tool that is so easy to accidentally run in an unmaintainable way. I also have some limited experience with Drone and Circle, but not enough to talk about them confidently.
hardwaresofton 3y ago
Off the top of my head: - Bring your own runner is easiest/most robust - environment deploys and management - tons of deployment integrations - DevSecOps features - Built in support ticket handling - Free container & package registry For most of these I’m pretty sure gitlab had them built into the platform (and free!) first
ak217 3y ago
They integrated in-repo configuration, self-hosted runners, composable workflow definitions, a robust API, and container building and registries for the first time in a CI tool. Of course GitHub came and blew that out of the water with a composable social actions ecosystem. Which was brilliant and remains the killer feature that puts GitHub far beyond reach of other CI platforms, especially now that they've improved in-repo composability a few months ago.
- capableweb 3y ago
  > They integrated in-repo configuration, self-hosted runners, composable workflow definitions, a robust API, and container building and registries for the first time in a CI tool. Out of those, I think only "composable workflow definitions" would be one of the features that other CI platforms didn't have, before GitLab even existed as a project. You might want to re-read the history and features of build platforms before GitLab.
  - ak217 3y ago
    I'm very familiar with the history of CI platforms before GitLab, having used Hudson, Jenkins, Circle, Travis, Appveyor, Codebuild, and a whole bunch of other platforms extensively. While some of them had these features, none of them had all of the features, few of them meaningfully integrated the features together, and most of them provided the features in a very half-assed and unreliable way.

dijksterhuis 3y ago

It’s possible to do ‘uses’ on GitLab, but there’s a few extras needed admittedly (branch name and path to file) include: https://gitlab.com/awesome-project/raw/main/.before-script-template.yml https://docs.gitlab.com/ee/ci/yaml/includes.html#include-a-single-configuration-file https://docs.gitlab.com/ee/ci/yaml/includes.html#include-a-s... But I agree, the social virality is what makes GitHub Actions what it is. I used to only visit a GL project when I needed to look through Nvidia cuda container builds… everything else I needed was on GH :shrugs:

trilbyglens 3y ago

Currently working on a gitlab api thing for work, and I gotta say their API us a complete joke. GitHub runs laps around them in this area. Gitlab is actually worse than bitbucket, believe it or not.

tomjakubowski 3y ago

Travis and Circle CI predated Gitlab, with YAML-configured workflows checked in to the repository and the ability to use custom images. GitlabCI's innovation was integration: making it a feature of repo hosting.

Ayesh 3y ago
I moved from Jenkins to Travis several years ago, and Travis's UI and configuration was such a fresh breath. Back then, pretty much _every_ OS project used it because of their generous offerings for open source projects. I agree with this comment that, and from my own experience living through the transitions, Travis CI made a massive leap leveling up the modern CI we have today.
hardwaresofton 3y ago
Yeah I didn’t say they innovated CI/CD — I said they innovated CI/CD as a platform-native offering!

pharmakom 3y ago

I find GitHub Actions incredibly counter-intuitive, personally.

dzhiurgis 3y ago
It’s the confusion between actions(basically third party plugins) and workflows(the ci that you are building for yourself) that got me.
- ambicapter 3y ago
  Thank you for finally explaining this to me (have had to deal with github ci off and on for months now).
- NameError 3y ago
  I think it was a mistake for Github to name the whole product "Actions" and then re-use the same word for a specific component within system. It's really natural to say something like "we need a push action for this repo" when it might be more correct to say "a push workflow"
  - voytec 3y ago
    > I think it was a mistake for Github to name the whole product "Actions" and then re-use the same word for a specific component within system. You're right: - product is called GitHub Actions - your workflow (consisting of jobs and steps) is a workflow - 3rd party workflow included in yours is an action, not workflow though - I more often hear engineers refer to workflows as actions But there are more annoying decisions - (org-wide) required workflows being recently deprecated - the feature was buggy (ie used alongside org-wide branch rules) - but could have been fixed, not deprecated - some kind of "marketplace" (with reviews, developers trust levels etc) for modular/pluggable actions (workflows) would be welcome; currently it's a "1st solution fitting the problem used" mess with little to no standarisation - I find the necessity to write a step cloning the repo from which a workflow is running ridiculous - it should be at most a single configuration line somewhere at the top of a workflow

chologrande 3y ago

How is Gitlab CI materially different from the jenkins model? I find that the only difference is that it's YAML - so even harder to debug, and maintains the same model where you must re run an entire pipeline every commit to test functionality.

robertlagrant 3y ago
You can run locally first to test functionality : - )
- chologrande 3y ago
  oh that's nice I didn't know that! Still a stickler on yaml for code though
- k_roy 3y ago
  how dare you suggest something so pedestrian.
hardwaresofton 3y ago
Yeah YAML isn’t ideal, but I personally found jenkins to be terrible to configure, not super well documented, missing features compared to an installation of gitlab (ex built in registry). Also the ability to rerun, target, and influence builds themselves is better on GitLab as well I think.

codethief 3y ago

> Gitlab CI is still the best CI in the game IMO, Oh god, if this is the best CI in the game, I don't want to be part of this game anymore. I work with (as in write pipeline code for) Gitlab CI almost every day and it's absolutely horrible. Not only does YAML lack any type safety whatsoever, but every day I run into yet another open ticket in the Gitlab issue tracker because using a declarative (YAML-based) approach (as opposed to an imperative one) essentially means that the Gitlab devs need to think of every possible use case beforehand, so as to be able to define a declaration & write an implementation for it. Clearly this is impossible, so now I'm banging my head against a wall on the daily.

thiht 3y ago
That’s not my experience at all. You do know you can run arbitrary shell scripts, and that means they don’t need to think of every possible use case? If your CI process is so complex that YAML + arbitrary code doesn’t work, you might want to get that checked, it’s not normal
- codethief 3y ago
  Random example: I want to define a setup job to build & push a base Docker image to our container registry. I then want to use this image as IMAGE in all subsequent jobs. This is impossible because the IMAGE field in YAML cannot be dynamic (determined at runtime) but I'd like to version/tag my image using the $CI_COMMIT_SHA.
  - nijave 3y ago
    Can't you use build time variables for this? https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job https://docs.gitlab.com/ee/ci/variables/#pass-an-environment...
    - codethief 3y ago
      I tried this but it didn't work.

j1elo 3y ago

I'm in the apparently small group of people who ignores 90% of the made & shared features, and push back against making internal ops to depend too much to any particular CI system. We know how to build, package, and release our software, and at work I firmly support that we write those operations as standalone scripts that in principle could even run in the developer's machine itself. Moving them to CI is just changing the machine that will run the scripts, and that's where I draw the line of how much coupling to accept with any given runner: run scripts, inject secrets, and maybe accumulate artifacts between jobs. There are a myriad of things done with Actions, such as preparing NPM, or running Docker containers. I see no point in them, you should be able to manually run the same commands, one by one, locally on a VM or empty Docker container, so at that point why not write them as a script. Use CI as a dumb shell runner. Getting to depend on all those small Actions saves 5 minutes today, only to make migrations immensely painful tomorrow.

wombatpm 3y ago
Especially if you have to run and deploy on your own servers. Not everything can be in the cloud.
gonzo41 3y ago
I agree with this, I recently had a pretty long network issue with our CI system and for the most part we just reran scripts or converted ci yml into scripts. I like CI for secrets management, scrpted pipelines and deploying. And having one button do do all of that. But all the extra junk people do with it seems like another thing to have break.
hardwaresofton 3y ago
I definitely agree with and do this — it only falls apart when CI environment stuff interferes with file locations and other external state. That said it is nice (if the scripts are simple) to do things like machine set up very easily.
physicsguy 3y ago
Same. I've also had to do things like migrate CI when a company was acquired, from Travis to Circle and Circle to GitLab in the past. It's very painful to do this if you've leaned into everything the CI service offers.

jakjak123 3y ago

Very good summary. I think both Gitlab CI and Github Actions are very good, but I think gitlab ci is more practical because of how easy it is to build custom advanced pipelines vs the great re-use of github actions.

DanielHB 3y ago

In my own project we actively cut down on external CI deps (non-official github actions) as much as possible, it seems incredible unsafe When we do use an external dep (like in two places for our massive project) we pin it to a specific GIT sha that we manually curated to not contain anything weird

Kelkonosemmel 3y ago

I love GitHub actions and think gitlab is okay. I found actions easier to use