Last Updated: February 25, 2016
· razielgn

Running Gitlab 6.8 on Rubinius 2

EDIT: Updated for GitLab 6.8!

Rubinius is a high performance Ruby implementation. Recently the Rubinius team released the 2.0 version. A lot of effort has been put in it, especially in the past year. It's got very mature and plays very nice with Rails.

GitLab is an "open source software to collaborate on code", written using Rails 3 and lots of other awesome tools from the Ruby world.

Running GitLab is a good way to show off the capabilities of Rubinius 2 when combined with a Web server that takes advantage of native threads and no global interpreter lock. In this case we're going to use Puma.

This guide is meant for people already familiar with installing GitLab on an Ubuntu/Debian machine. To get familiarity with it first, follow GitLab's official guide, which uses the canonical Ruby implementation (MRI).

Some familiarity with Linux and how it handles users and switching between them is also needed.

Tools in use

  • Ubuntu 12.04.3 LTS, but newer versions work just fine too.
  • chruby and ruby-installer, two amazing tools by postmodern.
  • GitLab 6.8, I'll update this every time GitLab releases might break this.

Let's go!

We're going to follow the official GitLab installation guide, taking detours when needed.

If a chapter has no content, it means you have to follow the steps from the official guide with no changes.

Let's get our hands dirty!

1. Packages / Dependencies

2. Ruby

First complete detour here.

We're going to install Rubinius by using ruby-install.

wget -O ruby-install-0.4.2.tar.gz
tar -xzvf ruby-install-0.4.2.tar.gz
cd ruby-install-0.4.2/
sudo make install


ruby-install rbx 2.2.6

This is going to install llvm, bison and unsurprisingly ruby1.9.1 aka Ruby 1.9.3, which is actually needed to build Rubinius itself.

Fear not: GitLab will be run by Rubinius, while GitLab shell by Ruby 1.9.3: it has a much lower startup time and GitLab shell processes are so short lived that the high performance JIT from Rubinius would totally be wasted there.

Now we're going to install chruby, which is going to be used by the user git (created later) to use Rubinius instead of the system installed Ruby 1.9.3.

wget -O chruby-0.3.8.tar.gz
tar -xzvf chruby-0.3.8.tar.gz
cd chruby-0.3.8/
sudo make install

3. System Users

4. GitLab shell

5. Database

6. GitLab

Clone the Source

Configure it

Just skip the steps regarding Unicorn.

Configure GitLab DB settings

When editing the DB configuration, set the pool to 16. You'll see why later.

Install Gems

Now we have to tell to the git user created in the paragraph "System Users" to use Rubinius:

echo 'source "/usr/local/share/chruby/"' >> /home/git/.profile
echo 'chruby "rbx"' >> /home/git/.profile

All the other steps in this section have to be typed after

su -l git

And without sudo -u git -H or sudo in front of them. Otherwise sudo wouldn't pick up the two lines we've added to /home/git/.profile, causing the system installed Ruby 1.9.3 to be used instead.

There are still some commands from the guide that have to be typed with sudo, you'll know which. To switch between git and root type exit and su git respectively.

Let's install Bundler.

gem install bundler --no-rdoc --no-ri

Now we have to tweak the Gemfile a bit.

Add at the end:

platform :rbx do
  gem "puma", "~> 2.8"
  gem "psych", "~> 2.0"

When running bundle install remove the --deployment flag, we've changed the Gemfile without updating Gemfile.lock in development, so it won't let us use it. Also add unicorn to the list of --without.

Our custom Gitlab Puma config:

wget -O "config/puma.rb" ""

Last but not least, the custom script/web file:

wget -O "script/web" ""

Initialize Database and Activate Advanced Features

Install Init Script

We're going to install a different init script, edited to make it work with Puma:

sudo wget -O "/etc/init.d/gitlab" ""

Perform the rest of the steps to make Gitlab start on boot.

Set up logrotate

Check Application Status

Compile assets

Start Your GitLab Instance

Before starting GitLab, recompile the assets. It's the best thing to do and I don't know why they don't do it in the official Guide.

bundle exec rake assets:precompile RAILS_ENV=production

Double-check Application Status

Errors you'll get:

  • Sidekiq is not running for the same reasons as above.
  • The init script is not up to date, because it's a custom one.

That's it!

Follow the rest of the steps (Nginx, …) and you're done!
Please report any problems you've encountered by following this guide, I'll be more than happy to help you.


I've set Puma to run 16 threads (same as the database connections pool configuration). If you need more units of concurrency, feel free to increase them, just remember to increase the pool database parameter too.