I've been enjoying GitLab at my last three employers now, with the CI integration being the most liberating feature compared to the traditional CI providers. Especially the Docker CI runner gives you a great integration test environment, and I'm impatiently waiting for this MR [0] that will allow dependant containers to also talk to each other. It's the last missing piece for my ideal CI setup.
Thanks for bringing this up I hadn't seen your contribution! I think this is a great idea. I know the technical team has been overwhelmed with community contributions as of late - which is a good problem to have but one that we're still solving. I'm going to try and shepherd this one along myself. If you want you can reach out to me on Twitter @olearycrew or my email is boleary [at] gitlab.
Ah sorry, my bad - I may have misread as well. Either way thanks for bringing it to my attention as I think this is a change that could make some other iterations "possible."
Edit: Saw that you are not the author of the merge request. Then thank you for highlighting it.
Oh jolly good! This exact feature was something I've thought about as useful for microservice stacks where you need interconnected background services for integration testing. Very nice of you to contribute this feature, thanks! Hopefully this will be merged at some point.
Gitlab API is amazingly simple and flexible, can be used efficiently from the terminal to list CI jobs, your issues, edit them,.. Gitlab CI is top-notch, things like CI_COMMIT_BEFORE_SHA environment variable for monorepos is a killer feature, now npm registry, .. Gitlab wiki for documentations
At work we are using Atlassian products, they would be so efficiently replaced by just Gitlab
Sadly not in situations where you need overview for more then one project. Viewing of mergerequest for all projects you have access to was disabled cause of performance problems.
Tangentially related, but GitLab has developed surprisingly good (albeit still incomplete) support for org-mode and many other markup languages. So it's extremely easy to publish say a wiki built with org and they render it beautifully.
I've found this invaluable for working solo or in group projects.
We've started using Gitlab where I work and it's so much better than GitHub. The built in CI and the activity view are features I just can't live without anymore. I also prefer Gitlab's merge requests to Github's PR system, and the UI overall is just tons better. The other thing is that GHE is an afterthought always behind github.com and with Gitlab, that's the main product, although gitlab.com is what we're using and it's gold. The only thing I miss is contribution stats which you have to pay extra for, and I hope we do.
I think Gitlab is awesome. However, their current homepage hides their actual site (the repositories) and makes it hard as a developer to actually get started compared to Github.
Looking through (browsing repositories) there is almost NO adoption to gitlab.
Gitlab Cloud v Github Cloud. Github cloud is easier to grok, and get started versus gitlab, adoption on github is very visible, and immediate from first landing.
Gitlab On Premise v Github Enterprise. Gitlab wins in offering (open source, and complete ci/cd). However, I would argue that the marketing is much stronger with Github. Github has a streamlined message which you can consume easily and then once you're in you get deeper into the meaning of.
This is what I am referring to. Model or not, it's something that is a barrier to entry.
(GitLab employee) What would you say GitHub does that makes it easier to get started on/adopt? I don't disagree, barriers to entry are just subjective so I'd like to hear your take
1. Straight to the point. For developers. Host code, work alongside millions of developers or your team.
2. Registration form right next to message. Immediate start. No need to think about much else. Let's get started.
3. Let me check their features (just in case) keep scrolling
4. Oh wow okay, woah another register form right here easy.
Gitlab:
1. Message makes me think. "A full DevOps tool~chain~.*" Why the asterisk? I'm already distracted.
2. Okay, I can manage projects, sourcecode management, CI/CD, great.
3. Get started for free...
4. Immediately see "try x for y days"... thinking "so is this paid?"
5. Look down and see I don't need to do that.
I have to do more thought now, why not just let me register from the homepage and auto-subscribe me to the gold plan and let me know that, you don't require a credit card either way.
---
This is purely from the Cloud perspective, but there is much more thinking required for Gitlab than Github.
---
Mind dump of subjectivity:
For hosted / feature-set, the way github illustrates their feature offering is much better than the table on the gitlab homepage as well. It's more about how much time do I have to vet a product. For someone who is purchasing enterprise they are more likely to invest more time, but overhead or information overload or time to trial is a real thing and can be quantified.
---
As a note, I like gitlab, the product is great, the marketing could use some work is all. Everyone there does a great job.
Thank you! That was really helpful. Sometimes you just get so familiar with something that you lose focus on what it's like to view it for the first time, I'll pass along your feedback
I like GitLab but noticed my Docker container running it is steadily requiring more memory to run smoothly. It’s sitting at 12GB right now, which is a little too high for my taste. I wish there were ways to reduce this.
Could you show the output of `ps aux` inside the container? Also note that GitLab Omnibus will add more Unicorn processes the more available RAM it has in the system. You can turn off that automatic scaling by lowering the number of processes via https://docs.gitlab.com/omnibus/settings/unicorn.html.
Thanks for the reply, here's my late response. I've pasted the output of ps aux here https://gist.github.com/maedoc/1f6e568d44541d7734204d294c98a..., though now it seems to have dropped significantly. The only change I seemed to have made that could account for that is moving from a local disk storage to NFS storage, maybe there's some caching accounting effect..
I have the same issue. Every once in a while the docker instance will get into a endless loop trying to start up and failing. So far the only fix I have found is to remove and recreate the instance. Still, I love having my own local GitLab.
Used GitLab maybe 5 years ago now? I was impressed with it despite its immaturity. These new features look great though.
I found the operation of on-prem GitLab to be a bit of a PITA back then, has that changed? There was a whole bunch of rake tasks and junk you needed to run to upgrade and it required a shutdown of the system.
Mainly just apt-get these days.
Occasionally something is deprecated in the config file, but the release notes are very clear. Never had an issue and our omnibus install has been chugging along since they introduced enterprise version back in the days.
It's a lot easier, and dead simple to run a small single server install. When you start scaling, it gets a little harder, but our vision it to leverage K8s for that type of deployment.
(Source: work at GitLab, and I wouldn't If we had to manage the infra by hand vs. omnibus/k8s)
Sure! This depends on your orgs "capacity for risk." We don't recommend more than ~300 on a single node just for the developer area. If you have 300 people relying on a literal SPOF (especially a dev shop) that's gonna hurt if there are any problems. That said, I'm aware of customers running a single 132GB node that serves somewhere between 3000-5000 devs. (Please do not go this far)
I'd say at the 150 or so developer mark, we should start talking about scaling (adding a second Geo node for failover at a minimum) or if you need more robust uptime requirements, going towards a more active-active distributed cluster. I use the word "distributed" and not "highly available" as we like to find the right fit for each org. Some orgs need true HA, and it takes something close to ~30 servers to do it. Others, just can benefit from some web frontends, and separating out the DB layer, and potentially traffic shaping to separate CI load / User load.
When I first used Gitlab on SmartOS it was a pain to upgrade manually.
I more recently used Gitlab on Ubuntu using their omnibus package for Ubuntu and the upgraded over multiple versions to get onto a later version of Gitlab. The upgrade process was a lot smoother (no fighting to build gems on SmartOS and patching all over the show to get gems and other dependencies to compile).
I also did a MySQL to Postgresql migration. You have a bit of downtime with the process which chef sorts things out post upgrade of the omnibus package. I did turn the unicorns and disabled ssh logins while I was upgrading the omnibus package just incase something went wrong during the upgrade.
Upgrade is usually as simple as an apt update && apt upgrade for me. Every once in a while they change tables in a non backwards compatible way and you have to force allow it or something. It's all very easy though.
Upgrading is super easy these days when you go with their omnibus installer. That handles all of the upgrade tasks for you, even skipping over versions which was not really possible with the source install days of old.
We're upgrading two or three times a month, and I don't remember having had any issue just letting it update itself for at least a year.
Gitlab's downtime when upgrading the docker image is about 1 - 3 minutes every time, which hasn't been an issue for us (and otherwise I'd just schedule it for midnight)
Well, I was able to deploy it on my home "server" within like half an hour. Migration when having hundreds of repos might be a bit more difficult, not sure about that of course.
If GitLab can pull off the npm registry well this might be the beginning of a universal package management server built into Gitlab. A bit like the self hosted Nexus registry or Artifactory.
You might not get as tight of integration as Gitlab will provide, but the Nexus OSS repository provides some nice features in terms of cleaning up old artifacts, some disk usage policies, etc.
I've been managing a small instance since version 5. There have been a few hiccups here and there, but mostly due on my part to not reading the release/upgrade notes carefully enough. Since version 8/9 it has been absolutely pain free. Run apt-get update then apt-get upgrade wait a bit and enjoy the new release!
To troubleshoot your problem smoothly, I'd advise not to modify your GitLab instance intentionally, for instance, applying own custom patch, changing database schema, etc.
I admin it for a small team of around 25. I've never had a failed upgrade, and have managed better uptime than Github and Gitlab, as it never gets DOS'd.
I previously managed Atlassian instances and I dreaded ever touching the servers.
GitLab def has there shit together in this regard.
edit: I forgot, when issue, their docker container uses tmp memory that never seems to free itself. I occasionally (once a year) have to rm and recreate the container, which isn't a huge deal for me.
I maintain several Atlassian products in addition to Gitlab on Ubuntu. Definitely agree - we have a whole snapshot / backup databases routine before going near the Atlassian boxes.
On-premise runs pretty much maintenance free. I've be running GitLab for ~5 years on-premise with ~200 developers. The issues have all been minimal, and few, over those years.
There are use cases where on prem is either very attractive or a requirement. We are currently on Github, but there part of me that would really really like to avoid spreading our code all over the Internet (we also use hosted CI) and trusting others. (Yes, Github is probably better at security than me etc ....) However others have very high security requirements where regulations are being violated by being off prem.
I've heard some people saying that the recent free private repos from github could potentially hurt or impact gitlab. I'm not entirely sure why since it is free stuff and not things you are paying for. Is there any merit to that or was I just listening to the wrong person? I'm thinking about applying there
I'd imagine the concern is reducing the earliest part of a customer funnel. First they get the free users. GitHub has the network effects and most open source projects using it, so gitlab need to be better in other areas like having free private repos. Then they can upsell these people for features, or be in the mind of someone making a decision on an enterprise license. If the early stage of that funnel is cut off, they lose their chance to get customers to the more profitable parts.
I've been enjoying GitLab at my last three employers now, with the CI integration being the most liberating feature compared to the traditional CI providers. Especially the Docker CI runner gives you a great integration test environment, and I'm impatiently waiting for this MR [0] that will allow dependant containers to also talk to each other. It's the last missing piece for my ideal CI setup.
[0] https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1...
GitLab product manager for Verify (CI) here.
Thanks for bringing this up I hadn't seen your contribution! I think this is a great idea. I know the technical team has been overwhelmed with community contributions as of late - which is a good problem to have but one that we're still solving. I'm going to try and shepherd this one along myself. If you want you can reach out to me on Twitter @olearycrew or my email is boleary [at] gitlab.
Great to hear you're looking into it! I do have to clarify that I'm not the owner of the MR though, not meaning to take credit of @krotscheck's work.
Ah sorry, my bad - I may have misread as well. Either way thanks for bringing it to my attention as I think this is a change that could make some other iterations "possible."
That thread looks rough. Kudos to the MR author for sticking it out.
@boleary-gl have you all considered having someone dedicate time each day / week to prioritizing community issues?
Ehn, it's no biggie. Tagir did most of the code (and owns the commits), I'm just a hominid rebase bot.
Edit: Saw that you are not the author of the merge request. Then thank you for highlighting it.
Oh jolly good! This exact feature was something I've thought about as useful for microservice stacks where you need interconnected background services for integration testing. Very nice of you to contribute this feature, thanks! Hopefully this will be merged at some point.
Gitlab API is amazingly simple and flexible, can be used efficiently from the terminal to list CI jobs, your issues, edit them,.. Gitlab CI is top-notch, things like CI_COMMIT_BEFORE_SHA environment variable for monorepos is a killer feature, now npm registry, .. Gitlab wiki for documentations
At work we are using Atlassian products, they would be so efficiently replaced by just Gitlab
Sadly not in situations where you need overview for more then one project. Viewing of mergerequest for all projects you have access to was disabled cause of performance problems.
Is there an issue for that? On the current version of GitLab https://gitlab.com/dashboard/merge_requests?assignee_usernam... loads in half a second https://www.dropbox.com/s/rfj1svopkexl6vb/Screenshot%202019-... and I have 1700 merge requests.
Maybe it was a regression in an old version?
Tangentially related, but GitLab has developed surprisingly good (albeit still incomplete) support for org-mode and many other markup languages. So it's extremely easy to publish say a wiki built with org and they render it beautifully.
I've found this invaluable for working solo or in group projects.
I definitely agree, because I use org-mode and gitlab, personally.
However, they are just using the same ruby package that Github uses to render the org-mode to HTML... unfortunately it is far from perfect.
Still, it's MUCH better than the go version in Gogs, so there's that.
I know, but on Gitlab you can additionally run an Emacs container to use org to export to HTML.
We've started using Gitlab where I work and it's so much better than GitHub. The built in CI and the activity view are features I just can't live without anymore. I also prefer Gitlab's merge requests to Github's PR system, and the UI overall is just tons better. The other thing is that GHE is an afterthought always behind github.com and with Gitlab, that's the main product, although gitlab.com is what we're using and it's gold. The only thing I miss is contribution stats which you have to pay extra for, and I hope we do.
I think Gitlab is awesome. However, their current homepage hides their actual site (the repositories) and makes it hard as a developer to actually get started compared to Github.
Looking through (browsing repositories) there is almost NO adoption to gitlab.
Well it seems like a very different model to Github.
I don't know the figures, but the teams I encounter using Gitlab are self-hosting, you aren't going to be able to browse their (private) repos.
GitLab is indeed used much more for private repositories than for open source. These are both on self-managed instances and GitLab.com
We used to have a Explore link on our homepage to https://gitlab.com/explore because HN asked for it but it got dropped.
I've asked to reinstate it in https://gitlab.com/gitlab-com/www-gitlab-com/issues/3713
Depends on what we are comparing.
Gitlab Cloud v Github Cloud. Github cloud is easier to grok, and get started versus gitlab, adoption on github is very visible, and immediate from first landing.
Gitlab On Premise v Github Enterprise. Gitlab wins in offering (open source, and complete ci/cd). However, I would argue that the marketing is much stronger with Github. Github has a streamlined message which you can consume easily and then once you're in you get deeper into the meaning of.
This is what I am referring to. Model or not, it's something that is a barrier to entry.
(GitLab employee) What would you say GitHub does that makes it easier to get started on/adopt? I don't disagree, barriers to entry are just subjective so I'd like to hear your take
Homepage Messaging:
Github:
1. Straight to the point. For developers. Host code, work alongside millions of developers or your team. 2. Registration form right next to message. Immediate start. No need to think about much else. Let's get started. 3. Let me check their features (just in case) keep scrolling 4. Oh wow okay, woah another register form right here easy.
Gitlab:
1. Message makes me think. "A full DevOps tool~chain~.*" Why the asterisk? I'm already distracted. 2. Okay, I can manage projects, sourcecode management, CI/CD, great. 3. Get started for free... 4. Immediately see "try x for y days"... thinking "so is this paid?" 5. Look down and see I don't need to do that.
I have to do more thought now, why not just let me register from the homepage and auto-subscribe me to the gold plan and let me know that, you don't require a credit card either way.
---
This is purely from the Cloud perspective, but there is much more thinking required for Gitlab than Github.
---
Mind dump of subjectivity:
For hosted / feature-set, the way github illustrates their feature offering is much better than the table on the gitlab homepage as well. It's more about how much time do I have to vet a product. For someone who is purchasing enterprise they are more likely to invest more time, but overhead or information overload or time to trial is a real thing and can be quantified.
---
As a note, I like gitlab, the product is great, the marketing could use some work is all. Everyone there does a great job.
Thank you! That was really helpful. Sometimes you just get so familiar with something that you lose focus on what it's like to view it for the first time, I'll pass along your feedback
Thanks for the feedback! I love the point about getting out of the way and starting on a gold plan. I'll discuss with our CMO.
I like GitLab but noticed my Docker container running it is steadily requiring more memory to run smoothly. It’s sitting at 12GB right now, which is a little too high for my taste. I wish there were ways to reduce this.
One of our Engineering Fellows is working Memory Optimization across the entire product this quarter. We are aware, and starting on it!
That fellow would be Stan, the person who just commented with https://news.ycombinator.com/item?id=18972052
Could you show the output of `ps aux` inside the container? Also note that GitLab Omnibus will add more Unicorn processes the more available RAM it has in the system. You can turn off that automatic scaling by lowering the number of processes via https://docs.gitlab.com/omnibus/settings/unicorn.html.
Thanks for the reply, here's my late response. I've pasted the output of ps aux here https://gist.github.com/maedoc/1f6e568d44541d7734204d294c98a..., though now it seems to have dropped significantly. The only change I seemed to have made that could account for that is moving from a local disk storage to NFS storage, maybe there's some caching accounting effect..
I occasionally have to rm my docker instance and recreate it.
I'm not sure what it's doing, but at least it's an easy fix.
I have the same issue. Every once in a while the docker instance will get into a endless loop trying to start up and failing. So far the only fix I have found is to remove and recreate the instance. Still, I love having my own local GitLab.
Sadly, too often GitLab is overlooked for a terrible GitHub+JIRA combo :-(
They are easier to use, really.
Used GitLab maybe 5 years ago now? I was impressed with it despite its immaturity. These new features look great though.
I found the operation of on-prem GitLab to be a bit of a PITA back then, has that changed? There was a whole bunch of rake tasks and junk you needed to run to upgrade and it required a shutdown of the system.
Mainly just apt-get these days. Occasionally something is deprecated in the config file, but the release notes are very clear. Never had an issue and our omnibus install has been chugging along since they introduced enterprise version back in the days.
It's a lot easier, and dead simple to run a small single server install. When you start scaling, it gets a little harder, but our vision it to leverage K8s for that type of deployment.
(Source: work at GitLab, and I wouldn't If we had to manage the infra by hand vs. omnibus/k8s)
Any comment on how well the single server install scales before needing to invest in the more complex HA solution?
Sure! This depends on your orgs "capacity for risk." We don't recommend more than ~300 on a single node just for the developer area. If you have 300 people relying on a literal SPOF (especially a dev shop) that's gonna hurt if there are any problems. That said, I'm aware of customers running a single 132GB node that serves somewhere between 3000-5000 devs. (Please do not go this far)
I'd say at the 150 or so developer mark, we should start talking about scaling (adding a second Geo node for failover at a minimum) or if you need more robust uptime requirements, going towards a more active-active distributed cluster. I use the word "distributed" and not "highly available" as we like to find the right fit for each org. Some orgs need true HA, and it takes something close to ~30 servers to do it. Others, just can benefit from some web frontends, and separating out the DB layer, and potentially traffic shaping to separate CI load / User load.
When I first used Gitlab on SmartOS it was a pain to upgrade manually.
I more recently used Gitlab on Ubuntu using their omnibus package for Ubuntu and the upgraded over multiple versions to get onto a later version of Gitlab. The upgrade process was a lot smoother (no fighting to build gems on SmartOS and patching all over the show to get gems and other dependencies to compile).
I also did a MySQL to Postgresql migration. You have a bit of downtime with the process which chef sorts things out post upgrade of the omnibus package. I did turn the unicorns and disabled ssh logins while I was upgrading the omnibus package just incase something went wrong during the upgrade.
Upgrade is usually as simple as an apt update && apt upgrade for me. Every once in a while they change tables in a non backwards compatible way and you have to force allow it or something. It's all very easy though.
Upgrading is super easy these days when you go with their omnibus installer. That handles all of the upgrade tasks for you, even skipping over versions which was not really possible with the source install days of old.
It's on docker, gitlab/gitlab-ce:latest
We're upgrading two or three times a month, and I don't remember having had any issue just letting it update itself for at least a year.
Gitlab's downtime when upgrading the docker image is about 1 - 3 minutes every time, which hasn't been an issue for us (and otherwise I'd just schedule it for midnight)
Well, I was able to deploy it on my home "server" within like half an hour. Migration when having hundreds of repos might be a bit more difficult, not sure about that of course.
If GitLab can pull off the npm registry well this might be the beginning of a universal package management server built into Gitlab. A bit like the self hosted Nexus registry or Artifactory.
Not sure if it wouldn't be just as well to run Nexus OSS instead though? https://www.sonatype.com/nexus-repository-oss
You might not get as tight of integration as Gitlab will provide, but the Nexus OSS repository provides some nice features in terms of cleaning up old artifacts, some disk usage policies, etc.
How well does on-premises Gitlab work? Can it run relatively maintenance-free? I heard some negative stories, but I don't know what is true.
My team of devs doesn't have a dedicated sysadmin.
I've been managing a small instance since version 5. There have been a few hiccups here and there, but mostly due on my part to not reading the release/upgrade notes carefully enough. Since version 8/9 it has been absolutely pain free. Run apt-get update then apt-get upgrade wait a bit and enjoy the new release!
It's basically maintenance-free, and if you got trouble, you can ask in Issue Tracker https://gitlab.com/gitlab-org/gitlab-ce/issues. We can advise how you can recover your instance case-by-case. (Also, there is a feature for backup your local data to cloud storage https://docs.gitlab.com/ee/raketasks/backup_restore.html. This is useful in case your machine'HDD died suddenly)
To troubleshoot your problem smoothly, I'd advise not to modify your GitLab instance intentionally, for instance, applying own custom patch, changing database schema, etc.
I admin it for a small team of around 25. I've never had a failed upgrade, and have managed better uptime than Github and Gitlab, as it never gets DOS'd.
I'm running GitLab via Docker, and I love it.
I previously managed Atlassian instances and I dreaded ever touching the servers.
GitLab def has there shit together in this regard.
edit: I forgot, when issue, their docker container uses tmp memory that never seems to free itself. I occasionally (once a year) have to rm and recreate the container, which isn't a huge deal for me.
I maintain several Atlassian products in addition to Gitlab on Ubuntu. Definitely agree - we have a whole snapshot / backup databases routine before going near the Atlassian boxes.
On-premise runs pretty much maintenance free. I've be running GitLab for ~5 years on-premise with ~200 developers. The issues have all been minimal, and few, over those years.
Why not cloud Gitlab?
There are use cases where on prem is either very attractive or a requirement. We are currently on Github, but there part of me that would really really like to avoid spreading our code all over the Internet (we also use hosted CI) and trusting others. (Yes, Github is probably better at security than me etc ....) However others have very high security requirements where regulations are being violated by being off prem.
I've heard some people saying that the recent free private repos from github could potentially hurt or impact gitlab. I'm not entirely sure why since it is free stuff and not things you are paying for. Is there any merit to that or was I just listening to the wrong person? I'm thinking about applying there
I'd imagine the concern is reducing the earliest part of a customer funnel. First they get the free users. GitHub has the network effects and most open source projects using it, so gitlab need to be better in other areas like having free private repos. Then they can upsell these people for features, or be in the mind of someone making a decision on an enterprise license. If the early stage of that funnel is cut off, they lose their chance to get customers to the more profitable parts.
Maybe, but to me, Gitlab's USP is features they offer that Github doesn't (like CI), not price.
Why only love for npm/JavaScript world? I still prefer having a separate registry for packages (e.g. SonaType Nexus) and let GitLab host code + CI
There are more planned. You can read it here: https://about.gitlab.com/direction/package/