rake gitlab:check complains about git version

With the 5.2 version of gitlab, the

bundle exec rake gitlab:check RAILS_ENV=production

command complains about the current distro’s version of git:

Your git bin path is “/usr/bin/git”
Git version >= 1.7.10 ? … no
Try fixing it:
Update your git to a version >= 1.7.10 from 1.7.9
Please fix the error above and rerun the checks.

Checking GitLab … Finished

Here’s how to compile from source to a local (or system wide) location.

Continue reading “rake gitlab:check complains about git version”

Fixing gitlab errors with git operations

Recenlty, I was able to install the 5.2 branch of gitlab for work.

I ran into the following error when cloning a repo:

git pull
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

yet, ssh and ssh keys were working:

ssh -T git@gitlab.lib.unc.edu
Welcome to GitLab, Anonymous!

It took a while, but I found a way to check what gitlab-shell is doing:


Check GitLab API access: FAILED. code: 302

Check directories and files:
/home/git/repositories: OK
/home/git/.ssh/authorized_keys: OK

This does make sense because it set up SSL in the apache conf for gitlab using the example conf file. It seems that gitlab-shell isn’t smart enough to handle a redirect to the https side. So in the gitlab-shell/config.yml make sure the gitlab_url setting has https set. Also, you may need to make sure your /etc/hosts has the name of the virtual host (if you are running it that way) pointing to the right interface.

Keep in mind, gitlab-shell doesn’t play nice with self-signed certs. I had to revert some things on another gitlab install.

After fixing this, ssh-ing into the server worked right:

ssh -T git@gitlab.lib.unc.edu
Welcome to GitLab, <user>!

Gitlab 5.1 – Adventures in upgrading from 5.0

I planned to upgrade later in the week hoping for a simple upgrade. But, I found myself upgrading despite my plans.

Of course, it had some issues. Here’s how I fixed them.

Problem 1:

Puma 2.0.0.b7 starting…
* Min threads: 0, max threads: 16
* Environment: production
* Listening on unix:///home/git/gitlab/tmp/sockets/gitlab.socket
/home/git/gitlab/vendor/bundle/ruby/1.9.1/gems/puma-2.0.0.b7/lib/puma/binder.rb:234:in `initialize’: Address already in use – /home/git/gitlab/tmp/sockets/gitlab.socket (Errno::EADDRINUSE)
from /home/git/gitlab/vendor/bundle/ruby/1.9.1/gems/puma-2.0.0.b7/lib/puma/binder.rb:234:in `new’
from /home/git/gitlab/vendor/bundle/ruby/1.9.1/gems/puma-2.0.0.b7/lib/puma/binder.rb:234:in `add_unix_listener’
from /home/git/gitlab/vendor/bundle/ruby/1.9.1/gems/puma-2.0.0.b7/lib/puma/binder.rb:96:in `block in parse’
from /home/git/gitlab/vendor/bundle/ruby/1.9.1/gems/puma-2.0.0.b7/lib/puma/binder.rb:64:in `each’
from /home/git/gitlab/vendor/bundle/ruby/1.9.1/gems/puma-2.0.0.b7/lib/puma/binder.rb:64:in `parse’
from /home/git/gitlab/vendor/bundle/ruby/1.9.1/gems/puma-2.0.0.b7/lib/puma/cli.rb:414:in `run_single’
from /home/git/gitlab/vendor/bundle/ruby/1.9.1/gems/puma-2.0.0.b7/lib/puma/cli.rb:402:in `run’
from /home/git/gitlab/vendor/bundle/ruby/1.9.1/gems/puma-2.0.0.b7/bin/puma:10:in `<top (required)>’
from /home/git/gitlab/vendor/bundle/ruby/1.9.1/bin/puma:23:in `load’
from /home/git/gitlab/vendor/bundle/ruby/1.9.1/bin/puma:23:in `<main>’

Thanks to this post it is simply fixed with:

sudo rm /home/git/gitlab/tmp/sockets/gitlab.socket

Yet, it still wasn’t running, so I ran:

sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production

and this minor annoyance came back:

GitLab Shell version? … FAIL. Please update gitlab-shell to v1.3.0

So, to fix that I did this in the /home/git/gitlab-shell directory:

sudo -u git -H git fetch

sudo -u git -H git checkout v1.3.0

Then, back in /home/git/gitlab, I did this:

sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production

and all was fine.

But it wasn’t. I couldn’t get anything to show in the browser. I do use apache rather than the default nginx.

So, let’s fix it so puma is running on a tcp port.

Comment out the below line in /home/git/gitlab/config/puma.rb

bind “unix://#{application_path}/tmp/sockets/gitlab.socket”

In your apache config, change the ProxyHost stanzas to port 9292 instead of 3000

That should do it.

One though i had based on memory usage now with puma, is wait. I wish I had. Unless you need fixes found in the CHANGELOG.

Update: Memory usage claims with puma seem to be as promised.