5 ms·

I wish they would spend a bit more time streamlining the installation procedure and/or streamlining dependencies. It looks like a great product, but attempting

I wish they would spend a bit more time streamlining the installation procedure and/or streamlining dependencies. It looks like a great product, but attempting to get it set up left me with the feeling that it's extremely bloated. And 2-4Gb recommended RAM is... a lot. I know, I'm bitching about something that they are giving away for free, but oh well.

mitchty 13y ago
Try not running it on ubuntu, or in a location that doesn't allow sudo to be setup to allow any command in quite the same way as the install docs assume. I've a forked version of their startup script that doesn't use sudo for the init script (honestly wtf why is this so common redis does the same). sudo the init script don't sudo in init scripts. Meh, its not too bad I'm at the point of 15 minutes to upgrade between releases so its not too bad but yeah it isn't a trivial install.
- sytse 13y ago
  Good to hear you managed to install without sudo. Does this mean you didn't create the git user? How did you solve the git@ urls for git over ssh connections? Did you use the init.d scripts?
  - mitchty 13y ago
    Nope, git user is created, but I just use su to do things as git. If you're running as root using sudo doesn't make sense, thats what su is for. https://gist.github.com/mitchty/6b9bc8c7dd41cd925b82#file-gitlab-sh-L42 https://gist.github.com/mitchty/6b9bc8c7dd41cd925b82#file-gi... Thats basically it, nothing overly special, just switched sudo for su mainly. I could test to see if i'm root and then su or then sudo but don't see a point.
    - sytse 13y ago
      I agree. In the installation manual most commands are 'sudo -u git', they run as the git user but they use sudo to make them foolproof (some people skip the instruction to login as the git user).
MetaCosm 13y ago
I guess it all depends on perspective. When I picked up Gitlab (18 months ago) -- the major competition was Gitorious -- which if you think Gitlab has a bad install -- you have no idea. Gitorious _had_ (haven't looked at it recently, I guess they spent a lot of time addressing this) the worst install I have ever seen (any package, ever, 15+ year in the industry) ... it seemed built for complexity just to generate them consulting / professional support hours. Gitlab in comparison was blissfully simple. As for the bloat... we have nearly 180 projects and 10+ user accounts, and while the baseline setup has a lot of bloat (I blame choice of language / framework) -- it generally works fairl well -- sometimes you have to kick Ruby.
- jeremiep 13y ago
  The installation pain can be largely removed by using chef.
- InclinedPlane 13y ago
  The really annoying part is upgrading. Which right now the instructions tell you to do bit by bit instead of whole hog. If you end up behind it makes it harder to catch up, which seems like a bad thing.
  - sytse 13y ago
    GitLab.com co-founder here. As you noted you should upgrade version by version. This makes sure everyone uses the same upgrade path so the single focus of the community is on making that path rock solid. This is annoying when you are a lot of versions behind. Maybe you can already guess my recommendation, consider upgrading more frequent :-)
    - bloodorange 13y ago
      As a user, it doesn't look nice to hear this from the developers. I think it would be nice to have a stable upgrade mechanism that doesn't break anything for people - or maybe an automated mechanism that does all the upgrades step by step so the user doesn't have to do much. Since I have seen this 'upgrade' problem repeatedly mentioned here, I think it would be a good problem to attack to help people feel more comfortable about using your product. I recently set up gitolite internally and this thread interests me because GitLab looks like something that could be considered for Git hosting. However, someone in my place may not be so comfortable with the idea when I get the general feeling that "upgrades are a pain". I only mean this as feedback to help you make your product more palatable (because I want to see a lot of good Git hosting solutions!)
azmenthe 13y ago
I set this up for use at my previous firm and it was extremely difficult and that was 2 years ago (so version 1 or 2 I think). It was great once it finally was up and running but I'd only recommend it if you have a legitimate intellectual property concern and can't use github enterprise.
- sytse 13y ago
  GitLab.com co-founder here. Installation got a lot simpler since 5.0 when you no longer had to install gitolite as well. I hope your upgrade will be smooth.
Zren 13y ago
Try Bitnami's installer. http://bitnami.com/stack/gitlab http://bitnami.com/stack/gitlab I have their VM iso running in a VBox Headless process and it idles at 44Mb. Mind you, it only get's minimal use.
mikewhy 13y ago
They continue to eschew using `foreman export` / `foreman run` / `bundle install --binstubs` in the docs, when it does simplify a lot of the installation / upgrade process. I've even sent pull requests that add capistrano / unattended deploy support that have gone nowhere. I love the software, but the installation / upgrade docs are always hell compared to your average `git pull && bin/rake db:migrate && foreman export`. Having said all that, I'm running it on an old box with 512MB of ran and it's tolerable.
- sytse 13y ago
  GitLab.com co-founder here. Thank you for the suggestions. There is a proposal in the core team to switch to --binstubs. We will also move the run logic from init.d to the bin directory so you can also use it with monit/god/bluepill/omnibus/chef/foreman.
616c 13y ago
If bloat is a concern, I used to use gitweb (which is Perl) over CGI on a sharer server and performed very well for my uses. All I had to do was write a short shell script to create the repo on the server, and SSH was running for me anyway (especially if I was going to push-pull). Now I use cgit, and discovered it a while before the Linux kernel did. [0] It is crazy fast (CGI written in C! Can you believe the nads on those guys?) and will be portable anywhere C is. If only I could get git's smart HTTP working, but I could not find much on the internet to clue me in. Still pretty cool. [0] http://comments.gmane.org/gmane.linux.kernel/1450151 http://comments.gmane.org/gmane.linux.kernel/1450151
sytse 13y ago
We're working hard on streamlining the installation but for now the focus is on a reliable installation method for most situations. The recommended RAM is 1GB, see https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/requirements.md https://github.com/gitlabhq/gitlabhq/blob/master/doc/install... (I'm a GitLab.com co-founder)
- binderbizingdos 13y ago
  Thanks for creating Gitlab. It helped us a lot internally. We were using plain Gitosis before. Now nobody gives a hoot about that anymore :) My only request would be to focus more on stability. We run it for 1 year now and there were many problems with upgrades and various changing issues with the different versions. So for us less new features but a better tested Gitlab would be great. Maybe some kind of "stable" release? Not sure...
  - sytse 13y ago
    Hi binderbizingdos, GitLab.com co-founder here. I'm glad to hear GitLab meets your needs. We know some upgrades have been painful, especially to 5.0 where Gitolite was removed. Since then we try to have smoother upgrades with complete documentation. Of course we can't avoid deprecation in major releases to move things forward. Each release is stable but if you want to be extra careful upgrade two weeks after release. But please let us know if there is anything specific we should focus on.
    - binderbizingdos 13y ago
      Thanks. Yes the upgrades are much better now. I think Gitlab kind of suffers from the Ubuntu syndrome when they were still pushing the non-LTS release as default. Many things were not tested long enough and would cause issues for many people while they were using it. For example after one upgrade browsing the repos didn't work because apparently the Git version hat to be a specific version. I think this was neither tested nor is the Git version mentioned anywhere as a requisite. Or with v5.3 the Git satellites would get into an unclean state sometimes and had to be cleaned out manually. I took quite some time to find this out too. So my suggestion: more polish and testing and less new features.
chappi42 13y ago
If you have problems with the installation use the free cloud service - nothing to setup. Or use vagrant (didn't try out myself). It is a great product and 'my' users love it (finally convinced them to move on from svn). One can copy-paste the instructions, it's rather lengthy but never had problems. It's wonderful what GitLab gives, thanks a lot!!
FooBarWidget 13y ago
I don't know why they recommend 2-4 GB RAM, but we're running Gitlab on 512 MB with Phusion Passenger Enterprise just fine. It also helps that Phusion Passenger Enterprise happens to use the least memory among all Ruby app servers.
- sytse 13y ago
  Good to hear 512MB works too. The recommended size is 1GB, see https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/requirements.md https://github.com/gitlabhq/gitlabhq/blob/master/doc/install...
  - benatkin 13y ago
    Did the recommended size change recently? If so, I'm a bit curious about when, and what changes were made that resulted in lower memory consumption.
    - sytse 13y ago
      It has been 1GB for quite a while.
Keyframe 13y ago
Turnkeylinux has a prepared image with it http://www.turnkeylinux.org/gitlab http://www.turnkeylinux.org/gitlab

mitchty 13y ago

Try not running it on ubuntu, or in a location that doesn't allow sudo to be setup to allow any command in quite the same way as the install docs assume. I've a forked version of their startup script that doesn't use sudo for the init script (honestly wtf why is this so common redis does the same). sudo the init script don't sudo in init scripts. Meh, its not too bad I'm at the point of 15 minutes to upgrade between releases so its not too bad but yeah it isn't a trivial install.

sytse 13y ago
Good to hear you managed to install without sudo. Does this mean you didn't create the git user? How did you solve the git@ urls for git over ssh connections? Did you use the init.d scripts?
- mitchty 13y ago
  Nope, git user is created, but I just use su to do things as git. If you're running as root using sudo doesn't make sense, thats what su is for. https://gist.github.com/mitchty/6b9bc8c7dd41cd925b82#file-gitlab-sh-L42 https://gist.github.com/mitchty/6b9bc8c7dd41cd925b82#file-gi... Thats basically it, nothing overly special, just switched sudo for su mainly. I could test to see if i'm root and then su or then sudo but don't see a point.
  - sytse 13y ago
    I agree. In the installation manual most commands are 'sudo -u git', they run as the git user but they use sudo to make them foolproof (some people skip the instruction to login as the git user).

MetaCosm 13y ago

I guess it all depends on perspective. When I picked up Gitlab (18 months ago) -- the major competition was Gitorious -- which if you think Gitlab has a bad install -- you have no idea. Gitorious _had_ (haven't looked at it recently, I guess they spent a lot of time addressing this) the worst install I have ever seen (any package, ever, 15+ year in the industry) ... it seemed built for complexity just to generate them consulting / professional support hours. Gitlab in comparison was blissfully simple. As for the bloat... we have nearly 180 projects and 10+ user accounts, and while the baseline setup has a lot of bloat (I blame choice of language / framework) -- it generally works fairl well -- sometimes you have to kick Ruby.

jeremiep 13y ago
The installation pain can be largely removed by using chef.
InclinedPlane 13y ago
The really annoying part is upgrading. Which right now the instructions tell you to do bit by bit instead of whole hog. If you end up behind it makes it harder to catch up, which seems like a bad thing.
- sytse 13y ago
  GitLab.com co-founder here. As you noted you should upgrade version by version. This makes sure everyone uses the same upgrade path so the single focus of the community is on making that path rock solid. This is annoying when you are a lot of versions behind. Maybe you can already guess my recommendation, consider upgrading more frequent :-)
  - bloodorange 13y ago
    As a user, it doesn't look nice to hear this from the developers. I think it would be nice to have a stable upgrade mechanism that doesn't break anything for people - or maybe an automated mechanism that does all the upgrades step by step so the user doesn't have to do much. Since I have seen this 'upgrade' problem repeatedly mentioned here, I think it would be a good problem to attack to help people feel more comfortable about using your product. I recently set up gitolite internally and this thread interests me because GitLab looks like something that could be considered for Git hosting. However, someone in my place may not be so comfortable with the idea when I get the general feeling that "upgrades are a pain". I only mean this as feedback to help you make your product more palatable (because I want to see a lot of good Git hosting solutions!)

azmenthe 13y ago

I set this up for use at my previous firm and it was extremely difficult and that was 2 years ago (so version 1 or 2 I think). It was great once it finally was up and running but I'd only recommend it if you have a legitimate intellectual property concern and can't use github enterprise.

sytse 13y ago
GitLab.com co-founder here. Installation got a lot simpler since 5.0 when you no longer had to install gitolite as well. I hope your upgrade will be smooth.

Zren 13y ago

Try Bitnami's installer. http://bitnami.com/stack/gitlab http://bitnami.com/stack/gitlab I have their VM iso running in a VBox Headless process and it idles at 44Mb. Mind you, it only get's minimal use.

mikewhy 13y ago

They continue to eschew using `foreman export` / `foreman run` / `bundle install --binstubs` in the docs, when it does simplify a lot of the installation / upgrade process. I've even sent pull requests that add capistrano / unattended deploy support that have gone nowhere. I love the software, but the installation / upgrade docs are always hell compared to your average `git pull && bin/rake db:migrate && foreman export`. Having said all that, I'm running it on an old box with 512MB of ran and it's tolerable.

sytse 13y ago
GitLab.com co-founder here. Thank you for the suggestions. There is a proposal in the core team to switch to --binstubs. We will also move the run logic from init.d to the bin directory so you can also use it with monit/god/bluepill/omnibus/chef/foreman.

616c 13y ago

If bloat is a concern, I used to use gitweb (which is Perl) over CGI on a sharer server and performed very well for my uses. All I had to do was write a short shell script to create the repo on the server, and SSH was running for me anyway (especially if I was going to push-pull). Now I use cgit, and discovered it a while before the Linux kernel did. [0] It is crazy fast (CGI written in C! Can you believe the nads on those guys?) and will be portable anywhere C is. If only I could get git's smart HTTP working, but I could not find much on the internet to clue me in. Still pretty cool. [0] http://comments.gmane.org/gmane.linux.kernel/1450151 http://comments.gmane.org/gmane.linux.kernel/1450151

sytse 13y ago

We're working hard on streamlining the installation but for now the focus is on a reliable installation method for most situations. The recommended RAM is 1GB, see https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/requirements.md https://github.com/gitlabhq/gitlabhq/blob/master/doc/install... (I'm a GitLab.com co-founder)

binderbizingdos 13y ago
Thanks for creating Gitlab. It helped us a lot internally. We were using plain Gitosis before. Now nobody gives a hoot about that anymore :) My only request would be to focus more on stability. We run it for 1 year now and there were many problems with upgrades and various changing issues with the different versions. So for us less new features but a better tested Gitlab would be great. Maybe some kind of "stable" release? Not sure...
- sytse 13y ago
  Hi binderbizingdos, GitLab.com co-founder here. I'm glad to hear GitLab meets your needs. We know some upgrades have been painful, especially to 5.0 where Gitolite was removed. Since then we try to have smoother upgrades with complete documentation. Of course we can't avoid deprecation in major releases to move things forward. Each release is stable but if you want to be extra careful upgrade two weeks after release. But please let us know if there is anything specific we should focus on.
  - binderbizingdos 13y ago
    Thanks. Yes the upgrades are much better now. I think Gitlab kind of suffers from the Ubuntu syndrome when they were still pushing the non-LTS release as default. Many things were not tested long enough and would cause issues for many people while they were using it. For example after one upgrade browsing the repos didn't work because apparently the Git version hat to be a specific version. I think this was neither tested nor is the Git version mentioned anywhere as a requisite. Or with v5.3 the Git satellites would get into an unclean state sometimes and had to be cleaned out manually. I took quite some time to find this out too. So my suggestion: more polish and testing and less new features.

chappi42 13y ago

If you have problems with the installation use the free cloud service - nothing to setup. Or use vagrant (didn't try out myself). It is a great product and 'my' users love it (finally convinced them to move on from svn). One can copy-paste the instructions, it's rather lengthy but never had problems. It's wonderful what GitLab gives, thanks a lot!!

FooBarWidget 13y ago

I don't know why they recommend 2-4 GB RAM, but we're running Gitlab on 512 MB with Phusion Passenger Enterprise just fine. It also helps that Phusion Passenger Enterprise happens to use the least memory among all Ruby app servers.

sytse 13y ago
Good to hear 512MB works too. The recommended size is 1GB, see https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/requirements.md https://github.com/gitlabhq/gitlabhq/blob/master/doc/install...
- benatkin 13y ago
  Did the recommended size change recently? If so, I'm a bit curious about when, and what changes were made that resulted in lower memory consumption.
  - sytse 13y ago
    It has been 1GB for quite a while.

Keyframe 13y ago

Turnkeylinux has a prepared image with it http://www.turnkeylinux.org/gitlab http://www.turnkeylinux.org/gitlab