No merge of a merge Request possible

If I want to Accept a merge request, I get the Following error:

January 25, 2015 14:54 -> ERROR -> Command failed [1]: /usr/bin/git --git-dir=/home/git/gitlab-satellites/example/EXAMPLE/.git --work-tree=/home/git/gitlab-satellites/example/EXAMPLE push origin master
remote: /home/git/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler/spec_set.rb:92:in `block in materialize': Could not find rake-10.3.2 in any of the sources (Bundler::GemNotFound)[K
remote: from /home/git/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler/spec_set.rb:85:in `map!'[K
remote: from /home/git/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler/spec_set.rb:85:in `materialize'[K
remote: from /home/git/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler/definition.rb:132:in `specs'[K
remote: from /home/git/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler/definition.rb:177:in `specs_for'[K
remote: from /home/git/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler/definition.rb:166:in `requested_specs'[K
remote: from /home/git/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler/environment.rb:18:in `requested_specs'[K
remote: from /home/git/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler/runtime.rb:13:in `setup'[K
remote: from /home/git/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler.rb:121:in `setup'[K
remote: from /home/git/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler/setup.rb:17:in `<top (required)>'[K
remote: from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'[K
remote: from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'[K
To /home/git/repositories/Alarm/ALARM.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to '/home/git/repositories/Alarm/ALARM.git'

System information
System:		Debian 7.8
Current User:	git
Using RVM:	yes
RVM Version:	1.26.9
Ruby Version:	2.1.5p273
Gem Version:	2.4.3
Bundler Version:1.7.6
Rake Version:	10.3.2
Sidekiq Version:2.17.8

GitLab information
Version:	7.7.1
Revision:	41ab9e1
Directory:	/home/git/gitlab
DB Adapter:	postgresql
URL:		https://gitlab.example.com
HTTP Clone URL:	https://gitlab.example.com/some-project.git
SSH Clone URL:	git@gitlab.example.com:some-project.git
Using LDAP:	no
Using Omniauth:	no

GitLab Shell
Version:	2.4.1
Repositories:	/home/git/repositories/
Hooks:		/home/git/gitlab-shell/hooks/
Git:		/usr/bin/git

bundle env|grep rake
      rake (>= 0.8.7)
      rake
      rake (>= 0.8.7)
    rake (10.3.2)

NOT using RVM is NOT POSSIBLE, because system Ruby is needed by an other application.

It seems that it's picking the wrong rake version because of having more than one rubies in your system. Have installed the one from source and the system one? If it's possible try removing the system ruby.

It is not possible to remove or upgrade system ruby, it is needed by an other application/programm.

Any suggestions how to tell rake the right environment?

Are there any solutions to fix that problem?

Gitlab is a beautiful peace of software, but the installation is not nice and the omnibus packages dont make it better

+1 (We need to keep the 1.9.1 packages for puppet)

System information
System:		Ubuntu 14.04
Current User:	git
Using RVM:	yes
RVM Version:	1.26.10
Ruby Version:	2.1.5p273
Gem Version:	2.4.3
Bundler Version:1.7.12
Rake Version:	10.3.2
Sidekiq Version:2.17.8

GitLab information
Version:	7.7.2
Revision:	98ef392
Directory:	/home/git/gitlab
DB Adapter:	mysql2
URL:		http://gitlab.example.com
HTTP Clone URL:	http://gitlab.example.com/some-project.git
SSH Clone URL:	git@gitlab.example.com:some-project.git
Using LDAP:	no
Using Omniauth:	no

GitLab Shell
Version:	2.4.2
Repositories:	/home/git/repositories/
Hooks:		/home/git/gitlab-shell/hooks/
Git:		/usr/bin/git

If you have gitlab using a ruby version installed in a non-standard location, this is probably caused by the forked "git receive-pack", which in turn executes the pre-receive hook (responbible for permission management, for instance). Git unconditionally adds "/usr/lib/git-core" and "/usr/bin" to the beginning of PATH before forking the hook, which means the hook runs with the system-wide ruby version, and not with the same version running the rest of gitlab. See git's receive-pack.c and exec_cmd.c (search for "setup_path").

A possible workaround is to plug a small wrapper script between git and the hooks, which simply does:

#!/bin/sh
if [ ! -z "$GITLAB_PATH_OUTSIDE_HOOK" ]; then
  export PATH=$GITLAB_PATH_OUTSIDE_HOOK
fi
exec $0.rb "$@"

And then symlink the hooks so that your gitlab-shell/hooks folder looks like this:

$ ls -l
total 16
-rwxrwxr-x 1 git git 193 Feb 20 13:53 hook_wrapper
lrwxrwxrwx 1 git git  12 Feb 20 13:32 post-receive -> hook_wrapper
-rwxrwxr-x 1 git git 423 Feb  2 11:10 post-receive.rb
lrwxrwxrwx 1 git git  12 Feb 20 13:48 pre-receive -> hook_wrapper
-rwxrwxr-x 1 git git 411 Feb 20 13:53 pre-receive.rb
lrwxrwxrwx 1 git git  12 Feb 20 13:32 update -> hook_wrapper
-rwxrwxr-x 1 git git 357 Feb  2 11:10 update.rb

(possibly replacing "git" with whatever user you have installed gitlab under)

A better solution would probably be to be able to directly tell git not to mangle the PATH variable.

FYI: I was able to get it to work by manually applying this Pull Request: https://github.com/gitlabhq/gitlabhq/pull/8356

I have the same problem, but finally I fixed that by removing ruby1.9 and keeping ruby2.1.

$sudo apt-get remove ruby1.9

Closing this for now since it seems to be solved and I cannot reproduce.

Status changed to closed