Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
I don’t think it makes any sense to mention source hut because none of the features you mentioned are killer features (or relevant. Why should I care about implementation details of feature tracking?) and it completely fails to address GitLab’s main value proposition: it’s CICD system.
Anyone can put up any ticketing system. They are a dime a dozen. Some version control systems even ship with their own. CICD is a whole different ballgame. It’s very hard to put together a CICD system that’s easy to manage and has a great developer experience. Not even GitHub managed to pull that off. GitLab is perhaps the only one who pulled this off. A yams file with a dozen or so lines is all it takes to get a pipeline that builds, tests, and delivers packages, and it’s easy to read and understand what happens. On top of that, it’s trivial to add your own task runners hosted anywhere in the world, in any way you’d like. GitLab basically solved this problem. That’s why people use it.
I use gitlab ci mainly and dabble in github actions. Can you clarify how “Not even Github managed to pull that off”? IIRC, actions is quite featureful and it’s open-source, so I assume that can be run with self-hosted runners as well.
Can you clarify how “Not even Github managed to pull that off”?
GitHub actions has an atrocious user experience, to the point that even a year or so ago people where doubting it was production-ready.
Sure, you can put together a pipeline. But I challenge anyone to try it out with GitHub actions and then just try to do the same with GitLab or even CircleCI or Travis.
The fact that people compare GitHub Actions go Jenkins of all things is everything anyone needs to know about it’s user experience.
I don’t think it makes any sense to mention source hut because none of the features you mentioned are killer features (or relevant. Why should I care about implementation details of feature tracking?) and it completely fails to address GitLab’s main value proposition: it’s CICD system.
Anyone can put up any ticketing system. They are a dime a dozen. Some version control systems even ship with their own. CICD is a whole different ballgame. It’s very hard to put together a CICD system that’s easy to manage and has a great developer experience. Not even GitHub managed to pull that off. GitLab is perhaps the only one who pulled this off. A yams file with a dozen or so lines is all it takes to get a pipeline that builds, tests, and delivers packages, and it’s easy to read and understand what happens. On top of that, it’s trivial to add your own task runners hosted anywhere in the world, in any way you’d like. GitLab basically solved this problem. That’s why people use it.
I use gitlab ci mainly and dabble in github actions. Can you clarify how “Not even Github managed to pull that off”? IIRC, actions is quite featureful and it’s open-source, so I assume that can be run with self-hosted runners as well.
Yep, at my previous job I moved a pretty complex build system from Jenkins to github actions. It worked fine and was much simpler to maintain.
And yes there are ways to run github actions on your own machine, but I haven’t tried it.
GitHub actions has an atrocious user experience, to the point that even a year or so ago people where doubting it was production-ready.
Sure, you can put together a pipeline. But I challenge anyone to try it out with GitHub actions and then just try to do the same with GitLab or even CircleCI or Travis.
The fact that people compare GitHub Actions go Jenkins of all things is everything anyone needs to know about it’s user experience.