Commit 7fd37b4f authored by Marin Jankovski's avatar Marin Jankovski

Remove vagrant related files.

parent 64575ad6
# -*- mode: ruby -*-
# vi: set ft=ruby :
# You can ask for more memory and cores when creating your Vagrant machine:
Vagrant.configure("2") do |config|
config.vm.hostname = "gitlab-dev" = "precise64"
config.vm.box_url = ""
config.vm.provider "vmware_fusion" do |vmware, override| = "precise64_fusion"
override.vm.box_url = ""
# Assign this VM to a host-only network IP, allowing you to access it
# via the IP. Host-only networks can talk to the host machine as well as
# any other machines on the same network, but cannot be accessed (through this
# network interface) by any external networks. :private_network, ip: "" :forwarded_port, guest: 3000, host: 3000 :forwarded_port, guest: 80, host: 8080
# We don't need to mount /vagrant directory since we use git user
# Using bindfs to remount synced folder in order to have the correct ownership
config.vm.synced_folder ".", "/vagrant", :disabled => true
config.vm.synced_folder "./home_git", "/git-nfs", :nfs => true
config.bindfs.bind_folder "/git-nfs", "/home/git", :owner => "1111", :group => "1111", :'create-as-user' => true, :perms => "u=rwx:g=rwx:o=rwx", :'create-with-perms' => "u=rwx:g=rwx:o=rwx", :'chown-ignore' => true, :'chgrp-ignore' => true, :'chmod-ignore' => true
config.vm.provider :virtualbox do |v|
# Use VBoxManage to customize the VM. For example to change memory:
v.customize ["modifyvm", :id, "--memory", MEMORY.to_i]
v.customize ["modifyvm", :id, "--cpus", CORES.to_i]
if CORES.to_i > 1
v.customize ["modifyvm", :id, "--ioapic", "on"]
config.vm.provider :vmware_fusion do |v, override|
override.vm.box_url = ""
v.vmx["memsize"] = MEMORY
v.vmx["numvcpus"] = CORES
config.vm.provider :parallels do |v, override|
v.customize ["set", :id, "--memsize", MEMORY, "--cpus", CORES]
# Install the version of Chef by the Vagrant Omnibus
# version is :latest or "11.4.0"
# Note:
# Using version "11.4.4" because that is the latest version
# AWS OpsWorks supports
config.omnibus.chef_version = "11.4.4"
# Enabling the Berkshelf plugin. To enable this globally, add this configuration
# option to your ~/.vagrant.d/Vagrantfile file
config.berkshelf.enabled = true
config.vm.provision :chef_solo do |chef|
chef.json = {
"gitlab" => {
"env" => "development",
"user_uid" => 1111,
"user_gid" => 1111
"phantomjs" => {
"version" => "1.8.1"
chef.run_list = [
# In case chef-solo run is failing silently
# uncomment the line below to enable debug log level.
chef.arguments = '-l debug'
# The script will login "git" user right away when doing "vagrant ssh"
Vagrant.configure("2") do |config|
config.vm.provision :shell, :path => "./"
# Disable sshd file permission checks. This is needed because our bindfs configuration
# uniformly applies liberal file permissions to /home/git .
Vagrant.configure("2") do |config|
config.vm.provision :shell, :path => "./"
# GitLab Vagrant virtual machine
*NOTE* Development with Vagrant virtual machine has been deprecated. The old setup guide has [been moved here](doc/ but we strongly recommend that it is not used as it is extremely slow and error prone.
*NOTE* Development with Vagrant virtual machine has been deprecated.
# GitLab Metal development setup
To develop GitLab, it is recommended to install a development GitLab on metal. This is much faster than any VM-based setup, but has as disadvantage that you might have to deal with anything that is already on your system.
There is also an option of setting up a dedicated OS for GitLab, see [the directions here](doc/
This guide is tested and confirmed working on:
......@@ -97,7 +96,7 @@ cd /home/USER/gitlab/gitlab
and follow [the readme instructions to run it in development mode](
*Note* SSH push won't work on metal setup but you can still clone and push by using `http`.
*Note* SSH push won't work on metal setup but you can still clone and push using `http`.
# Troubleshooting and limitations
# Development installation on a Dedicated OS
*It is possible and recommended to [develop GitLab on your existing OS](, if you do want to use a dedicated OS for development please use the guide below.*
# Introduction
The downside of installing a dedicated OS (possibly on the same HD as the existing one) is that it takes up a little time (~30 minutes if you know what your are doing) to install and disk space (30GB should be more than enough).
If you chose this option, do *not* create the `git` user at installation time: use the same username that you use on your existing system. This cookbook will create a correctly configured `git` user for you.
Once you have installed your dedicated system and logged in, the installation process is the same as that for the existing system.
If you chose to use a dedicated OS, you have the following options of how to develop.
## Git user on the dedicated OS
The advantage of running as the `git` user is that it is very easy to start up the server and run tests. Just do:
cd gitlab
bundle exec foreman start
firefox localhost:3000
And your server will be running.
Using the `git` user has the following downsides:
- you have to reinstall every development program that you use (editors, browsers, etc.)
- you have to find a way to copy all your configurations under your existing OS's home to the git home.
The problem is that it is not possible to use `mount` because the home folder is used by Gitlab.
One option is to use git to store your configurations + a script that symlinks files to your home folder,
such as done in [Zack Holam's dotfiles](
## Non-Git user on the dedicated OS
The advantage of this option is that you can reuse your existing OS's `/home` folder by mounting it.
Furthermore, there will be no interference between your home directory and the `git` home directory.
You do still have to reinstall all your development programs, and there is a small chance that they will interfere with those that Gitlab uses.
First make sure that your username on the dedicated OS is the same as the username on your existing OS.
Next, mount your existing OS's home directory on your dedicated OS's home by adding a line like the following line to your `/etc/fstab`:
echo "UUID=$UUID /media/home ext4 defaults 0 0" | sudo tee -a /etc/fstab
where you can find `UUID` via `sudo blkid` and `sudo lsblk -f`.
Get the home directory out of the way and symlink into the main system's home:
cd /home
sudo mv "$USER" "$USER".bak
sudo ln -s /media/home/home/"$USER" "$USER"
To be able to edit the Gitlab files easily, use `bindfs` to bind the Gitlab folder to your home directory under a different username.
To do that automatically on every startup on Ubuntu use the following:
sudo apt-get install bindfs
mkdir -p ~/gitlab
#mkdir -p ~/gitlab-shell
#mkdir -p ~/repositories
#mkdir -p ~/gitlab-ci
#mkdir -p ~/gitlab-satellites
#mkdir -p ~/gitlab-ci-runner
sudo tee /etc/init/bindfs-gitlab.conf << EOF
description "Bindfs mount gitlab for development user."
# Can only mount when mountall has mounted the home from the main system.
start on stopped mountall
bindfs -u ciro -g ciro --create-for-user=git --create-for-group=git /home/git/gitlab /home/ciro/gitlab
# Uncomment as needed:
#bindfs -u ciro -g ciro --create-for-user=git --create-for-group=git /home/git/gitlab-satellites /home/ciro/gitlab-satellites
#bindfs -u ciro -g ciro --create-for-user=git --create-for-group=git /home/git/repositories /home/ciro/repositories
#bindfs -u ciro -g ciro --create-for-user=git --create-for-group=git /home/git/gitlab-shell /home/ciro/gitlab-shell
#bindfs -u ciro -g ciro --create-for-user=gitlab_ci --create-for-group=gitlab_ci /home/gitlab_ci/gitlab-ci /home/ciro/gitlab-ci
#bindfs -u ciro -g ciro --create-for-user=gitlab_ci_runner --create-for-group=gitlab_ci_runner /home/gitlab_ci_runner/gitlab-ci-runner /home/ciro/gitlab-ci-runner
end script
From now on your `~/gitlab` directory will be synced with the `git` user `~/gitlab` directory, but it will seem to you that you are the owner of the files.
Also, if your create any files, the `git` user will still see them with owner `git`.
To be able to run graphical programs while logged in as `git` you need to do as your development user:
xhost +
which you can add to your `.~/profile`.
This will enable your to see letter opener emails or Capybara `save_and_open_page` if your tests fail.
Whenever you start a new shell to develop, do `sudo su git`, and you are ready for the usual
cd ~/gitlab
bundle exec foreman start
firefox localhost:3000
## Deprecation warning
This guide has been deprecated, please do not use it as this way of development setup is not being maintained anymore.
### Development installation on a virtual machine with Vagrant
### Requirements
* [Ruby 1.9 or higher]( and [Rubygems](
* [VirtualBox](
* [Vagrant 1.4.0](
* The NFS packages for the synced folder of Vagrant. These are already installed if you are using Mac OSX and not necessary if you are using Windows. On Linux install them by running:
sudo apt-get install nfs-kernel-server nfs-common portmap
Make sure to use Vagrant v1.3.5. Do not install Vagrant via as there exists an old gem which will probably cause errors. Instead, go to [Vagrant download page]( and install version `1.3.5`.
On OS X you can also choose to use [the (commercial) Vagrant VMware Fusion plugin]( instead of VirtualBox.
### Speed notice
Running in Vagrant is slow compared to running in a metal (non-virtualized) environment. To run your tests at an acceptable speed we recommend using the [Spork application preloader]( If you run `bundle exec spork` before running a single test it completes 4 to 10 times faster after the initial run.
Time of `time be rspec spec/models/project_spec.rb` on a Intel core i5 processor with 6GB:
- Metal without spork: 53 seconds
- Metal with spork: 16 seconds
- Virtualbox without spork: 298 seconds (almost 5 minutes)
- Virtualbox with Spork: 32 seconds
The paid [VMware Fusion]( is a little faster than Virtualbox but it doesn't make a big difference. In it does seem to be more stable than Virtualbox, so consider it if you encounter problems running Virtualbox.
Rails 4.1 comes with the [Spring application preloader](, when we upgrade to Rails 4.1 that will replace Spork.
If you are frequently developing GitLab you can consider installing all the development dependencies on your [metal environment](
### Installation
We assume you already have a working Ruby and Rubygems installation.
`Vagrantfile` already contains the correct attributes so in order use this cookbook in a development environment following steps are needed:
1. Check if you have a gem version of Vagrant installed:
gem list vagrant
If it lists a version of vagrant, remove it with:
gem uninstall vagrant
Next steps are:
vagrant plugin install vagrant-berkshelf --plugin-version 1.3.7
vagrant plugin install vagrant-omnibus
vagrant plugin install vagrant-bindfs
git clone
cd ./cookbook-gitlab
bundle install
vagrant up --provision
If you have VMWare Fusion and the Vagrant VMWare Fusion provider you can opt to use that instead of the VirtualBox provider. Follow all of the steps above except substitute the following vagrant up command instead:
vagrant up --provider=vmware_fusion --provision
By default the VM uses 1.5GB of memory and 2 CPU cores. If you want to use more memory or cores you can use the GITLAB_VAGRANT_MEMORY and GITLAB_VAGRANT_CORES environment variables:
You can't use a vagrant project on an encrypted partition (ie. it won't work if your home directory is encrypted).
You'll be asked for your password to set up NFS shares.
Also note that if you are using a firewall on the host machine, it should allow the NFS related traffic,
otherwise you might encouter NFS mounting errors during `vagrant up` like:
mount.nfs: mount to NFS server '.../cookbook-gitlab/home_git' failed: timed out, giving up
### Running the tests
Once everything is done you can log into the virtual machine and run the tests as the git user:
vagrant ssh
cd /home/git/gitlab/
bundle exec rake gitlab:test
### Start the Gitlab application
cd /home/git/gitlab/
bundle exec foreman start
You should also configure your own remote since by default it's going to grab
gitlab's master branch.
git remote add mine git://
# or if you prefer set up your origin as your own repository
git remote set-url origin git://
#### Accessing the application
`` or your server for your first GitLab login.
#### Virtual Machine Management
When done just log out with `^D` and suspend the virtual machine
vagrant suspend
then, resume to hack again
vagrant resume
vagrant halt
to shutdown the virtual machine, and
vagrant up
to boot it again.
You can find out the state of a virtual machine anytime by invoking
vagrant status
Finally, to completely wipe the virtual machine from the disk **destroying all its contents**:
vagrant destroy # DANGER: all is gone
### OpenLDAP
If you need to setup OpenLDAP in order to test the functionality you can use the [basic OpenLDAP setup guide](doc/
### Updating
The gitlabhq version is _not_ updated when you rebuild your virtual machine with the following command:
vagrant destroy && vagrant up
You must update it yourself by going to the gitlabhq subdirectory in the gitlab-vagrant-vm repo and pulling the latest changes:
cd gitlabhq && git pull --ff origin master
A bit of background on why this is needed. When you run 'vagrant up' there is a checkout action in the recipe that points to [gitlabhq repo]( You won't see any difference when running 'git status' in the cookbook-gitlab repo because the cloned directory is in the [.gitignore]( You can update the gitlabhq repo yourself or remove the home_git so the repo is checked out again.
if [ ! -f /home/git/.profile ]; then
echo 'echo You are now logged in as the git user that runs GitLab, to get sudo privileges please exit to become the vagrant user' | su git -c 'cat >> /home/git/.profile'
cat /home/vagrant/.bashrc | grep --quiet 'sudo su - git' || echo 'sudo su - git' >> /home/vagrant/.bashrc
if cat /etc/ssh/sshd_config | grep --quiet "StrictModes yes"; then
sed -i 's!StrictModes yes!StrictModes no!g' /etc/ssh/sshd_config
service ssh restart
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment