I was running GitLab on a VPS with specs close to the lower end of the recommended requirements and its performance would gradually slow down over the course of the day until pages seemed to never finish loading. Restarting gitlab got it responding properly again, but the whole process would repeat over and over again, so that it had to be restarted every couple of hours just to be able to use it.
I then switched providers, which also came with more system resources, and GitLab was working without any issues right away. It could have been caused by an oversold node at the previous host, or the slightly higher system specs at the new host made the difference, but I've been running GitLab on that new server for a couple of months now without experiencing those slowdowns again.
If you've noticed a gradual slowdown to the point of pages getting stuck on loading indefinitely, then try to up the system specs a bit, as it could make quite the difference.
Kudos to the GitLab team. I've been running it for 12 months now on premises. The Omnibus package makes the instance unbelievable easy to install and upgrade, so there's no excuse not to run the latest versions. I've just been watching my instance get better and better over those 12 months, better UI, more features and better performance. I really love the software and can't talk it up enough.
I've been using gitlab for the past few weeks to host a couple of repositories, it's awesome so far since it's the only solution that allowed me to mirror a repo AND create my own branch on the mirrored repository.
The only complaint I really have is the fact that I have to append a ".git" to the http url to clone the repository. Alternatively, it'd be nice to have a git:// read only url too.
The git:// protocol requires its own daemon (which is bundled with Git) running on port 9418 https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco... . The standard Git daemon is unsuitable for GitLab I think because of the way it manages access control.
The question is then: how badly do people want this and how many admins out there are willing to poke an extra hole in their firewall just for this protocol.
I finally decided to give GitLab a shot, and so far things are going pretty well. You can make an account with your GitHub login, and you can migrate projects with just one click. From there I just had to set a password for my account, and now I'm pushing commits with no trouble at all. The whole process took just a few minutes, pretty cool!
I literally just spun up an instance of gitlab today. I'm regretting using bitnami's version though... all their documentation is out of date, and they change a lot of defaults and break things. It's been an unpleasant experience.
That said. A fresh instance of bitbucket hosted close to our office vs bitbucket? No contest.
Thanks for trying GitLab! We're not happy with the Bitnami version, from https://about.gitlab.com/installation/ "One-click installers are frequently out of date and might not contain our Omnibus packages. An example of this are the Bitnami packages in the past couldn't be updated and are now much harder to update than the Omnibus packages. We advise to not use one-click installers but instead start an vanilla Ubuntu 14.04 instance and use the recommended Omnibus package installation. This is almost as quick as a one-click install and you're sure of the latest version and easy upgrades."
While the Omnibus packages are nice, focusing on them and neglect the gitlab-only packages makes life harder for other group of people.
Some of us want to reuse the pgsql/redis instances we are already running. For example, we already have pgsql for redmine and other uses, we don't want another, separate instance. Too bad that standalone packages working with system supplied (debian, centos) packages are non-existent.
We understand the appeal of native packages. There have never been any gitlab-only packages, so I don't think we're able to neglect them. In fact, we've been sponsoring Pirate Praveen to bring native packages to Debian and this is really close at the moment, see http://feedback.gitlab.com/forums/176466-deprecated-feedback...
This is great! I moved my team's repos to GitLab last year and I love it. Pricing is better, there's more granularity in assigning team member roles, and the mobile app is good too.
Unrelated but I signed up on the hosted gitlab and I imported some repos from github (worked flawlessly and was very easy) but I got stuck at the .travis.yml -> .gitlab-ci.yml since the documentation on the CI is not too great (or I didn't it).
Is there a plan to convert or support travis ci config? If not, would it be possible to get a repo example for each language. I think i've seen something similar but there was only 1-2 examples
Been using gitlab for a while and its mostly good. The only thing that is letting it down for us is the code review tools which are not as good as some of the other dedicated tools on the market. The big gripes are:
* the ability to assign a review to multiple users
* set a number of reviewers
* Multiline comments
* review publishing
* Review versions
Not really noticed any problems with speed but its good to see that they are working on it anyway :)
Yes saw that. Currently evaluating various git servers as its something we use a lot. But would really want to assign the review to particular (or a group of) people i.e. the more experienced people in a team.
Thinking about it not sure that this is really necessary in the git world. Back in svn days seeing the diffs versioned was handy but with merge request you can see the commit history so its not necessary.
We've been using Gitlab with my team for the past year or so. Moved from corporate Github to it. It's really nice and almost flawless so far. When i tried to install it, at some point, to a VPS of mine i had several issues with ruby packages etc. I might give it another go, it seems like the latest versions have been improved significantly.
Thank you for the post, it is always great reading performance reports they make you think twice next time you develop software and question if you got any "code smells" to work on in your own code as well.
I then switched providers, which also came with more system resources, and GitLab was working without any issues right away. It could have been caused by an oversold node at the previous host, or the slightly higher system specs at the new host made the difference, but I've been running GitLab on that new server for a couple of months now without experiencing those slowdowns again.
If you've noticed a gradual slowdown to the point of pages getting stuck on loading indefinitely, then try to up the system specs a bit, as it could make quite the difference.