Would also like a write-up. People assume it's just because of GitHub outages, but GitHub is slightly worse in every aspect, so for big projects and organisations it compounds to being quite messy to manage and operate.
GitLab is thought-out to support larger groups with more complex pipelines, and while it's got it's own set of quirks, it doesn't begin to compare, GitHub in contrast seems like a toy forge for toy projects.
Having used GitLab pipelines, I would definitely not describe it as well thought out. Their method of forcing all jobs/pipelines for a repo through one file controlled with a load of ‘if’ rules is a complete mess. Makes running multiple pipelines for one repo a huge PITA.
Compared to GitHub Actions or Jenkins its a pretty poor experience
This only happens on poorly thought pipelines and GitHub actions model or Jenkins high level directives won't make up for it. Eventually it'll break.
In Gitlab you can use the main file for describing high level stage pathways (tests, builds, deployments...) and offload individual control of jobs to granular files. Tests can be self contained child pipelines. Templates make them easy to replicate and components give them more flexibility.
You can do a lot more than GitHub actions with a lot less complexity than Jenkins.
And of course many people self-host which changes a lot of the equation (which you can also do with GitHub, but not for free - and FWIW our self-hosted premium gitlab has about an hour a day downtime, which we've been told by the team responsible is an unavoidable side-effect of backing up gitlab).
I was responsible for administering a self hosted GitLab instance for a medium sized company and our backups never required downtime. The built in backup command doesn't require downtime but also isn't a consistent point in time snapshot (specifically because the instance keeps running while the backup is being taken). If they've decided they need one for some reason, stopping GitLab is certainly the easiest way, but not the only way of accomplishing that goal, but that'll be true of any self-hosted forge, including GitHub.
What makes it more complicated than doing a Git push against two remotes? Assuming that one of those is used for collaboration and the other is just a mirror.
Would also like a write-up. People assume it's just because of GitHub outages, but GitHub is slightly worse in every aspect, so for big projects and organisations it compounds to being quite messy to manage and operate.
GitLab is thought-out to support larger groups with more complex pipelines, and while it's got it's own set of quirks, it doesn't begin to compare, GitHub in contrast seems like a toy forge for toy projects.
Having used GitLab pipelines, I would definitely not describe it as well thought out. Their method of forcing all jobs/pipelines for a repo through one file controlled with a load of ‘if’ rules is a complete mess. Makes running multiple pipelines for one repo a huge PITA. Compared to GitHub Actions or Jenkins its a pretty poor experience
This only happens on poorly thought pipelines and GitHub actions model or Jenkins high level directives won't make up for it. Eventually it'll break.
In Gitlab you can use the main file for describing high level stage pathways (tests, builds, deployments...) and offload individual control of jobs to granular files. Tests can be self contained child pipelines. Templates make them easy to replicate and components give them more flexibility.
You can do a lot more than GitHub actions with a lot less complexity than Jenkins.
why? like having a dozen outages in the last couple months isn't a good enough reason why?
GitLab is just as bad, just not as big so doesn't get the coverage. https://status.gitlab.com/pages/history/5b36dc6502d06804c083...
And of course many people self-host which changes a lot of the equation (which you can also do with GitHub, but not for free - and FWIW our self-hosted premium gitlab has about an hour a day downtime, which we've been told by the team responsible is an unavoidable side-effect of backing up gitlab).
I was responsible for administering a self hosted GitLab instance for a medium sized company and our backups never required downtime. The built in backup command doesn't require downtime but also isn't a consistent point in time snapshot (specifically because the instance keeps running while the backup is being taken). If they've decided they need one for some reason, stopping GitLab is certainly the easiest way, but not the only way of accomplishing that goal, but that'll be true of any self-hosted forge, including GitHub.
5 replies →
Weird. I’ve been on a self hosted enterprise gitlab and I think we’ve have only one or two performance degradations/outages in the past 6 years
3 replies →
No horse in this race but GitLab has been down a few times recently too.
Considering the sheer volume GitHub received lately I wouldn’t be surprised if GitLab would experience similar issues unless self hosted.
Or what do you think?
Or Microsoft/OpenAI (and others) just blatantly scraping all your codebases and violating thousands of OSS licneses?
If the repos are public, hosting location doesn't make a difference.
2 replies →
We're going to need something more expansive than OSI software licenses for the future.
Something like, "if you look at us, we must be able to look at you"
2 replies →
Roku uses Gitlab internally so could just be a standardization thing.
Moving changes back and forth between gitlab and github is a pain. Could indeed be as simple as standardization and reducing development pains.
What makes it more complicated than doing a Git push against two remotes? Assuming that one of those is used for collaboration and the other is just a mirror.
2 replies →
Probably the lack of transparency regarding AI and AI accounts. They don't require any declaration..