I have used both of the popular services for work and quite recently I got my hands on GitHub Actions as well. So, I decided to present an opinionated comparison between CI/CD offerings from both in the context of simply building a docker image of an application and then pushing it to their respective container registry services.

.github/workflows/build-image.yml

name: Docker Image CI

on:
  push:
    branches: [ main ]

env:
  REGISTRY: ghcr.io

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Docker meta
      id: meta
      uses: docker/metadata-action@v3
      with:
        images: backend

    - name: Log in to the Container registry
      uses: docker/login-action@v1
      with:
        registry: ${{ env.REGISTRY }}
        username: ${{ github.actor }}
        password: ${{ github.token }}

    - name: Build and push Docker image
      uses: docker/build-push-action@v2
      with:
        context: ./backend
        push: true
        tags: ghcr.io/my-org/my-repo/backend:${{ github.run_number }}

.gitlab-ci.yml

image: docker:stable

services:
  - docker:dind

build-docker:
  only:
    - master
  tags:
    - docker
  script:
    - docker build -t registry.gitlab.com/my-org/my-repo .
    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com
    - docker push registry.gitlab.com/my-org/my-repo

• GitHub takes a more standard and verbose approach compared to GitLab in terms of their .yml file exposing more options for configuration which is why it might be a bit longer to look at.

• GitHub brings the power of its open-source community by making the pipeline a plug-n-play system where you can bring in already available "actions" that someone else might have already built. In the above case, we are using actions built by docker themselves which is missing on the GitLab side. With GitLab you get more control by writing the commands manually but becomes a repetitive task as well.

• In GitLab you might need to make some configuration changes from CI/CD settings to enable Shared GitLab Runners but in GitHub that's not required or visible.

• GitLab will show you all the available runners but with GitHub its transparent and you choose the host os through the configuration yml file. GitHub also supports more host os like MacOS.

• GitLab designed the pipeline system as a docker container so, in order to spawn our docker container we need a service like dind which stands for docker in docker but with GitHub all of that is abstracted away from us due to using already built actions.

• You can have your own private hosted runners for both due to compliance reasons.

• With GitLab you can make a move from their cloud to on-prem host everything on your own but with GitHub, since their platform is not open-source (ironic), you can move between cloud and enterprise on-prem hosting.

I particularly don't prefer one from the other. It basically depends on which service your organization is on.