1. 18
  1.  

  2. 16

    GitLab have had CI/CD for ages and it works great, I get that git hub ci is also nice but it feels overly hyped? Does it bring something that other providers lack?

    1. 12

      I don’t get how OP can write such a post and not mention GitLab. Reminds me of Apple’s habit of adopting old tech (e.g. NFC) and calling it “innovative”.

      1. 1

        This reads a lot like a paid advertisement. Fail to consider alternatives that have existed for years? Check. Do not mention anything bad/negative? Check.

      2. 5

        Yeah, doesn’t look to me like there’s anything that Gitlab hasn’t been doing for a while already. I guess I can understand the hype though, a few months I set up Gitlab CI for one of the project I’m working on at my current job and to somebody who’s never done this before it looks cool and exciting.

        1. 2

          Something that surprised me was the ability to schedule workflows to run regularly – it eliminated a cronjob from a VPS and keeps the schedule with the code.

          1. 5

            You can do this in gitlab-ci too.

            1. 1

              Neat! I had no idea.

      3. 10

        I don’t use Github and only use Gitlab as a mirror. In general it’s better to avoid features which get you stuck to the platform in a manner where you can’t easily move away later.

        1. 3

          Since they were acquired by Microsoft, GitHub is doubling down on their “value-added” model. There should be a point where those additions should be standardised in some extent though, because that lock-in might become a big issue in the future.

          1. 6

            I don’t think it’s in microsoft’s best interest to ‘standardize’ with other CI services. They want to lock you in.

            1. 6

              There’s a book out there about how big change won’t occur until a disaster strikes. It might be “Lessons of Disaster” but I’m not sure if that was it. It was pretty convincing and gave good examples in history. Most importantly, the book showed how a lot of safety laws are implemented, not when people raise concerns, but after many people die from the lack of such laws. It takes a disaster to implement disaster preventions.

              I think that might happen to a lot of FOSS communities, where people talking about how it’s bad to get locked-in to a proprietor/vendor won’t be taken seriously (to the point of action) until disaster strikes. It probably won’t happen for a while and won’t be as dramatic, but I think there’s a good possibility that without standardization/decentralization, many will eventually be confronted with the pain that is vendor lock-in.

              I think Fossil has the right idea about including the issue tracker, wiki, etc. in the decentralized repos. I hope we see more solutions like that come up and see adoption.

              1. 2

                There should be a point where those additions should be standardised in some extent though, because that lock-in might become a big issue in the future.

                For you, or for the org tasked with maximizing the number of mouths at the feeding trough?

              2. 1

                features which get you stuck

                Are you talking about GitHub actions or GitLab CI here?

                Because I don’t think that is much of a problem for GitLab CI. Since your jobs are purely script based, it’s quite easy to transition to different platforms. Yes, you can create stages, job dependencies and what not, but still.

              3. 12

                What’s the hot take? This is just saying it’s good