← Back to context

Comment by robswc

16 hours ago

GitHub is such a mess. They seem to be doing everything and nothing. GitLab is 100x better, in terms of DX. While I still have a soft spot for GH, its frustrating to use it when GL exists.

13 comments

robswc

Reply
CodesInChaos  16 hours ago

Downtime aside, what do prefer about GitLab?

  • robswc  8 hours ago

    In general, the foundations upon which it was built.

    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.

  • locknitpicker  15 hours ago

    GitLab has a top of the class CICD system that is leaps and bounds over GitHub Actions. That alone makes it worth using GitLab.

    • jesse_faden  6 hours ago

      I don't understand why GitLab CI is praised so much when it is the most limited and unintuitive ones of all the CI systems I've worked with.

      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: bash

      1 reply →