5 ms·

Last time i was installing gitlab after having the nightmare to install and maintain a gitorious installation and was really depressed that it felt like the sam

by buster 14y ago

Last time i was installing gitlab after having the nightmare to install and maintain a gitorious installation and was really depressed that it felt like the same nightmare. Pages of pages of copy&paste instructions, followed by half a dozen issues that needed post-install fixing... no, never again.. I ended up installing gitblit and was amazed by the quick installation and features. Unpack&run! I can recommend gitblit to everyone who needs a quick&easy to install Git web frontend.. But gitlab definitely looks nicer, probably can do even more.. it has pull requests which are (yet) missing in gitblit.

mbreese 14y ago
I had the same issue a month or so ago. I needed to install a local Git repository and because I'd be working with people who had never used Git before, I wanted to have some kind of GUI for them. I looked at GitLab, Gitolite + gitweb, and Gitosis. GitLab's installation was the worst of the three. It was horrible, and seemed like it would have been impossible to maintain/upgrade. I really hope that the entire experience has improved. I ended up using Gitosis, and while I don't quite like the workflow, the installation was pretty easy (there was a bash script to run that installed and configured everything). I'm going to evaluate the new version of GitLab, but if the installation process isn't better, I'll just stick with Gitosis.
- oso96_2000 14y ago
  I'm nowhere near a ruby developer, so i don't understand how most of the things works, but had cero trouble installing gitlab. Even when it throws some strange (for me) errors on some gems, it was just a matter of googling to solve the problem.
  - buster 14y ago
    Some years back i was able to tolerate when a webapp needed serious fiddling in a) apache configs, b) php configs and c) manual mysql database setup. Nowaday i expect something to run and have as few steps to install as possible. It wasn't even so much the many steps in between but the stuff that just didn't work as given in the installation guide. Turned out that some answers were in the gitlab Troubleshooting Guide. And then some stuff just didn't work, because at that point resque was removed (if i remember correctly, i don't even know what resque is and i don't really care, tbh). Now, after this took me 2 hours to get it running, half a day was spent with a) log in, b) find something not working, c) google, d) log into server and fix, e) repeat. I'm no ruby guy, too, but i would've thought this goes much smoother nowadays. I was using Gitlab for 1 or 2 weeks back then, but when the password reset didn't work it really made me think if i want to go through all that again on the next major update. So i turned to gitblit (which i rejected before because it can't do pull requests). Edit: Don't get me wrong, i liked the Gitlab interface, it's very polished and nice, and what was working was working fine. Still i wouldn't want to maintain it. Maybe it's all better now with 5.0 :)
    - sytse 14y ago
      I'm sorry to hear you had trouble installing GitLab before. Installation should be a lot better now. We replaced resque with sidekick. Also there are pre installed images available from http://bitnami.com/stack/gitlab http://bitnami.com/stack/gitlab
      - buster 14y ago
        Ah, sounds great. I think you should really advertise those packages more! To be honest the 5.0 installation guide still looks terribly long. No way i would go through that again. BUT now there are packages.. hopefully for 5.0 soon.
        sytse 14y ago
        Good point. When the packages are updated to 5.0 I'll submit a merge request for the readme.
- rektide 14y ago
  Gitolite- the old git repo for gitlab- is a cherished joy around here; we love it, it's both easy to use & has mad useful features. qa* users can commit to qa* branches? Sure, np. I have a hard time sympathizing with Gitolite being removed for it's complexity. GitLab switching to their own stuff to make their side of the equation easier, to make their software less complex to write and configure, otoh might be a thing. I'd just need nominated yesterday to start trying to install it alongside Gitolite! I wonder if they made a crack at being able to read and parse gitolite.conf files and use those configs to power gitlab? That would've been a happier path for me personally for smoothing out gitlab configuration hell, more so than writing a new repo server that we're not likely to qualify & then adopt, not when Gitolite is our living beating heart.
  - sytse 14y ago
    FYI It is hard to use Gitolite config files in GitLab since GitLab already stores the configuration and premissions in the database.
    - rektide 14y ago
      thanks. my proposal was that perhaps there should be a script that can do much of the db configuration based off of what is in a gitolite.conf file.
picomancer 14y ago
Installation is actually a problem with Rails, and web app development as a whole. Think about PHP: Drop files in the web server directory, add a database and user, edit the app configuration file to point to said database and user, and you're done. Then there's Rails apps. Gitolite is actually fairly typical: Install a ton of packages (including ssh, redis, and postfix daemons which need to be secured), compile your own Ruby (and keep it up to date), install the Bundler gem, configure Gitlab, configure Gitlab shell, configure Unicorn, configure the database, install gems with bundler, bundle exec rake gitlab:setup RAILS_ENV=production (I have no idea what this does), install an init script, update your rc.d, then set up an nginx reverse proxy [1]. If you're used to setting up web apps, this is typical, and very well-described by the provided instructions. If you're used to the PHP experience, or you've only ever installed distro-packaged apps with apt-get or equivalent, this process feels really unreasonably long and painful. I remember that the Discourse folks said that they were aware that installation was a pain point, and they were working on making it easier. Lowering the barriers to installation is actually something that web applications written in Ruby/Python/Node.js really need to do in order to begin to compete with PHP solutions among more casual administrators. A big part of the problem is isolation from the system package manager. I have a Redmine install on the same server as Gitolite, which I manage via apt-get. I'd really like to have a version of the Gitlab instructions that keeps non-system packages (like the self-compiled Ruby) self-contained in /home/git, so they don't break anything else. [1] https://github.com/gitlabhq/gitlabhq/blob/5-0-stable/doc/install/installation.md https://github.com/gitlabhq/gitlabhq/blob/5-0-stable/doc/ins...
- dewiz 14y ago
  ...compete with PHP, seriously? Many of the points above apply to any language. Ruby might have maintainability issue but PHP is far far from perfect.
  - sorbits 14y ago
    The point is very valid. The person who has to install some third party web application is mainly concerned with “how easy is this to install”. Not only have I steered clear of installing things with too many alien prerequisites, I’m often writing in PHP only because deployment is just so much easier.

by buster 14y ago

mbreese 14y ago

I had the same issue a month or so ago. I needed to install a local Git repository and because I'd be working with people who had never used Git before, I wanted to have some kind of GUI for them. I looked at GitLab, Gitolite + gitweb, and Gitosis. GitLab's installation was the worst of the three. It was horrible, and seemed like it would have been impossible to maintain/upgrade. I really hope that the entire experience has improved. I ended up using Gitosis, and while I don't quite like the workflow, the installation was pretty easy (there was a bash script to run that installed and configured everything). I'm going to evaluate the new version of GitLab, but if the installation process isn't better, I'll just stick with Gitosis.

oso96_2000 14y ago
I'm nowhere near a ruby developer, so i don't understand how most of the things works, but had cero trouble installing gitlab. Even when it throws some strange (for me) errors on some gems, it was just a matter of googling to solve the problem.
- buster 14y ago
  Some years back i was able to tolerate when a webapp needed serious fiddling in a) apache configs, b) php configs and c) manual mysql database setup. Nowaday i expect something to run and have as few steps to install as possible. It wasn't even so much the many steps in between but the stuff that just didn't work as given in the installation guide. Turned out that some answers were in the gitlab Troubleshooting Guide. And then some stuff just didn't work, because at that point resque was removed (if i remember correctly, i don't even know what resque is and i don't really care, tbh). Now, after this took me 2 hours to get it running, half a day was spent with a) log in, b) find something not working, c) google, d) log into server and fix, e) repeat. I'm no ruby guy, too, but i would've thought this goes much smoother nowadays. I was using Gitlab for 1 or 2 weeks back then, but when the password reset didn't work it really made me think if i want to go through all that again on the next major update. So i turned to gitblit (which i rejected before because it can't do pull requests). Edit: Don't get me wrong, i liked the Gitlab interface, it's very polished and nice, and what was working was working fine. Still i wouldn't want to maintain it. Maybe it's all better now with 5.0 :)
  - sytse 14y ago
    I'm sorry to hear you had trouble installing GitLab before. Installation should be a lot better now. We replaced resque with sidekick. Also there are pre installed images available from http://bitnami.com/stack/gitlab http://bitnami.com/stack/gitlab
    - buster 14y ago
      Ah, sounds great. I think you should really advertise those packages more! To be honest the 5.0 installation guide still looks terribly long. No way i would go through that again. BUT now there are packages.. hopefully for 5.0 soon.
      - sytse 14y ago
        Good point. When the packages are updated to 5.0 I'll submit a merge request for the readme.
rektide 14y ago
Gitolite- the old git repo for gitlab- is a cherished joy around here; we love it, it's both easy to use & has mad useful features. qa* users can commit to qa* branches? Sure, np. I have a hard time sympathizing with Gitolite being removed for it's complexity. GitLab switching to their own stuff to make their side of the equation easier, to make their software less complex to write and configure, otoh might be a thing. I'd just need nominated yesterday to start trying to install it alongside Gitolite! I wonder if they made a crack at being able to read and parse gitolite.conf files and use those configs to power gitlab? That would've been a happier path for me personally for smoothing out gitlab configuration hell, more so than writing a new repo server that we're not likely to qualify & then adopt, not when Gitolite is our living beating heart.
- sytse 14y ago
  FYI It is hard to use Gitolite config files in GitLab since GitLab already stores the configuration and premissions in the database.
  - rektide 14y ago
    thanks. my proposal was that perhaps there should be a script that can do much of the db configuration based off of what is in a gitolite.conf file.

picomancer 14y ago

Installation is actually a problem with Rails, and web app development as a whole. Think about PHP: Drop files in the web server directory, add a database and user, edit the app configuration file to point to said database and user, and you're done. Then there's Rails apps. Gitolite is actually fairly typical: Install a ton of packages (including ssh, redis, and postfix daemons which need to be secured), compile your own Ruby (and keep it up to date), install the Bundler gem, configure Gitlab, configure Gitlab shell, configure Unicorn, configure the database, install gems with bundler, bundle exec rake gitlab:setup RAILS_ENV=production (I have no idea what this does), install an init script, update your rc.d, then set up an nginx reverse proxy [1]. If you're used to setting up web apps, this is typical, and very well-described by the provided instructions. If you're used to the PHP experience, or you've only ever installed distro-packaged apps with apt-get or equivalent, this process feels really unreasonably long and painful. I remember that the Discourse folks said that they were aware that installation was a pain point, and they were working on making it easier. Lowering the barriers to installation is actually something that web applications written in Ruby/Python/Node.js really need to do in order to begin to compete with PHP solutions among more casual administrators. A big part of the problem is isolation from the system package manager. I have a Redmine install on the same server as Gitolite, which I manage via apt-get. I'd really like to have a version of the Gitlab instructions that keeps non-system packages (like the self-compiled Ruby) self-contained in /home/git, so they don't break anything else. [1] https://github.com/gitlabhq/gitlabhq/blob/5-0-stable/doc/install/installation.md https://github.com/gitlabhq/gitlabhq/blob/5-0-stable/doc/ins...

dewiz 14y ago
...compete with PHP, seriously? Many of the points above apply to any language. Ruby might have maintainability issue but PHP is far far from perfect.
- sorbits 14y ago
  The point is very valid. The person who has to install some third party web application is mainly concerned with “how easy is this to install”. Not only have I steered clear of installing things with too many alien prerequisites, I’m often writing in PHP only because deployment is just so much easier.