Merge branch '6-5-release' into 'master'

WIP 6 5 Release

gitlab/Berksfile

@@ -2,4 +2,6 @@ site :opscode
 metadata
+cookbook 'yum', tag: 'v2.4.4'
 cookbook 'magic_shell', git: 'git://github.com/customink-webops/magic_shell.git', ref: '447b4b67420d3a7a749d2dd3b13a7f9aceb54c36'
+cookbook 'monit', git: 'git://github.com/phlipper/chef-monit.git', tag: '1.4.0'

gitlab/Berksfile.lock

@@ -3,11 +3,19 @@
     "gitlab": {
       "path": "."
     },
+    "yum": {
+      "locked_version": "2.4.2"
+    },
     "magic_shell": {
       "locked_version": "0.3.2",
       "git": "git://github.com/customink-webops/magic_shell.git",
       "ref": "447b4b67420d3a7a749d2dd3b13a7f9aceb54c36"
     },
+    "monit": {
+      "locked_version": "1.4.0",
+      "git": "git://github.com/phlipper/chef-monit.git",
+      "ref": "276c99ba08869ebd5117267d91a2ff6aa0d9fc6b"
+    },
     "redisio": {
       "locked_version": "1.7.0"
     },
@@ -30,7 +38,7 @@
       "locked_version": "1.1.0"
     },
     "mysql": {
-      "locked_version": "2.1.2"
+      "locked_version": "4.0.6"
     },
     "database": {
       "locked_version": "1.5.2"
@@ -44,9 +52,6 @@
     "postfix": {
       "locked_version": "3.0.4"
     },
-    "yum": {
-      "locked_version": "2.4.2"
-    },
     "phantomjs": {
       "locked_version": "1.0.3"
     },

gitlab/CONTRIBUTING.md

+# Contribute to the GitLab Cookbook
+
+This guide details how to use issues and merge requests to improve GitLab.
+
+-  [Contributor license agreement](#contributor-license-agreement)
+-  [Security vulnerabilities](#security-vulnerability disclosure)
+-  [Closing policy for issues and merge requests](#closing-policy-for-issues-and-merge-requests)
+-  [Issue tracker](#issue-tracker)
+-  [Merge requests](#merge-requests)
+
+## Contributor license agreement
+
+By submitting code as an individual you agree to the [individual contributor license agreement](doc/legal/individual_contributor_license_agreement.md). By submitting code as an entity you agree to the [corporate contributor license agreement](doc/legal/corporate_contributor_license_agreement.md).
+
+## Security vulnerability disclosure
+
+Please report suspected security vulnerabilities in private to support@gitlab.com, also see the [disclosure section on the GitLab.com website](http://www.gitlab.com/disclosure/). Please do NOT create publicly viewable issues for suspected security vulnerabilities.
+
+## Closing policy for issues and merge requests
+
+GitLab is a popular open source project and the capacity to deal with issues and merge requests is limited. Out of respect for our volunteers, issues and merge requests not in line with the guidelines listed in this document may be closed without notice.
+
+Please treat our volunteers with courtesy and respect, it will go a long way towards getting your issue resolved.
+
+Issues and merge requests should be in English and contain appropriate language for audiences of all ages.
+
+## Issue tracker
+
+The [issue tracker](https://gitlab.com/gitlab-org/cookbook-gitlab/issues) is only for obvious bugs or misbehavior. When submitting an issue please conform to the issue submission guidelines listed below. Not all issues will be addressed and your issue is more likely to be addressed if you submit a merge request which partially or fully addresses the issue.
+
+Do not use the issue tracker for feature requests. We have a specific [feedback and suggestions forum](http://feedback.gitlab.com/forums/176466-general/category/77454-gitlab-cookbook) for this purpose.
+
+Please send a merge request with a tested solution or a merge request with a failing test instead of opening an issue if you can.
+
+### Issue tracker guidelines
+
+Search for similar entries before submitting your own, there's a good chance somebody else had the same issue. Show your support with `:+1:` and/or join the discussion. Please submit issues in the following format (as the first post):
+
+1. **Summary:** Summarize your issue in one sentence (what goes wrong, what did you expect to happen)
+2. **Steps to reproduce:** How can we reproduce the issue
+3. **Expected behavior:** Describe your issue in detail
+4. **Observed behavior**
+5. **Relevant logs and/or screenshots:** Please use code blocks (\`\`\`) to format console output, logs, and code as it's very hard to read otherwise.
+6. **Versions** Which OS, Vagrant version, Vagrant plugins, Chef version and Ruby version are you using?
+7. **Possible fixes**: If you can, link to the line of code that might be responsible for the problem
+
+## Merge requests
+
+We welcome [merge requests](https://gitlab.com/gitlab-org/cookbook-gitlab/merge_requests) with fixes and improvements to code, tests, and/or documentation.
+
+### Merge request guidelines
+
+If you can, please submit a merge request with the fix or improvements including tests. If you don't know how to fix the issue but can write a test that exposes the issue we will accept that as well. In general bug fixes that include a regression test are merged quickly while new features without proper tests are least likely to receive timely feedback. The workflow to make a merge request is as follows:
+
+1. Fork the project
+1. Create a feature branch
+1. Write tests and code
+1. It must contain passing `chefspec` tests
+1. Test it on multiple platforms
+1. Add your changes to the [CHANGELOG](CHANGELOG)
+1. If you have multiple commits please combine them into one commit by [squashing them](http://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
+1. Push the commit to your fork
+1. Submit a merge request and explain in description what it does and which platforms it is run on and which platforms are untested
+1. Find [issues](https://dev.gitlab.org/gitlab/cookbook-gitlab/issues) related to your merge request and mention them in the merge request description
+
+We will accept merge requests if:
+
+* The code has proper tests and all tests pass (or it is a test exposing a failure in existing code)
+* It can be merged without problems (if not please use: `git rebase master`)
+* It does not break any existing functionality
+* It's quality code that conforms to the [Ruby](https://github.com/bbatsov/ruby-style-guide) and [Rails](https://github.com/bbatsov/rails-style-guide) style guides and best practices
+* The description includes a motive for your change and the method you used to achieve it
+* It is not a catch all merge request but rather fixes a specific issue or implements a specific feature
+* It keeps the GitLab code base clean and well structured
+* We think other users will benefit from the same functionality
+* If it makes changes to the UI the merge request should include screenshots
+* It is a single commit (please use `git rebase -i` to squash commits)
+
+For examples of feedback on merge requests please look at already [closed merge requests](https://gitlab.com/gitlab-org/cookbook-gitlab/merge_requests?label_name=&milestone_id=&scope=&state=closed).

gitlab/README.md

@@ -3,11 +3,11 @@ GitLab Cookbook
 Chef cookbook with recipes to install GitLab and its dependencies:
-* GitLab: 6.2
-* GitLab Shell: 1.7.9
+* GitLab: 6.5
+* GitLab Shell: 1.8.0
 * Ruby: 2.0.0p353
 * Redis: 2.6.13
-* Git: 1.7.12
+* Git: 1.8.4.1
 * Nginx: 1.1.19
 * PostgreSQL: 9.1.9
 * MySQL: 5.5.34
@@ -23,46 +23,14 @@ Cookbook has been tested and it is known to work on:
 * [Development installation on a virtual machine with Vagrant](doc/development.md)
+* [Development installation on metal (outside a Virtual Machine)](doc/development_metal.md). May run much faster than inside a VM.
+
 * [Production installation on Amazon Web Services (AWS) with Vagrant](doc/aws_vagrant.md)
 * [Production installation with Chef Solo](doc/production.md)
 If you want to do a production installation using AWS Opsworks please see the [cookbook for GitLab on AWS Opsworks repository](https://gitlab.com/gitlab-com/cookbook-gitlab-opsworks/blob/master/README.md).
-## Database
-
-Default database for this cookbook is `mysql`.
-To override default credentials for the database supply the following json to the node:
-
-```json
-{
-  "mysql": {
-    "server_root_password": "rootpass",
-    "server_repl_password": "replpass",
-    "server_debian_password": "debianpass"
-  },
-  "gitlab": {
-    "database_password": "datapass"
-  }
-}
-```
-
-To use `postgresql` override default credentials by supplying the following json to the node:
-
-```json
-{
-  "posgtresql": {
-    "password": {
-      "postgres": "psqlpass"
-    }
-  },
-  "gitlab": {
-    "database_adapter": "postgresql",
-    "database_password": "datapass",
-  }
-}
-```
-
 ## Recipes
 ### clone
@@ -167,19 +135,11 @@ bundle exec rspec
 ## Acknowledgements
-This cookbook was based on a [cookbbook by ogom](https://github.com/ogom/cookbook-gitlab). Thank you ogom!
-
-We would also like to thank Eric G. Wolfe for making the [first cookbook for CentOS](https://github.com/atomic-penguin/cookbook-gitlab). Thank Eric!
+This cookbook was based on a [cookbbook by ogom](https://github.com/ogom/cookbook-gitlab), thank you ogom! We would also like to thank Eric G. Wolfe for making the [first cookbook for CentOS](https://github.com/atomic-penguin/cookbook-gitlab), thanks Eric!
 ## Contributing
-We welcome all contributions.
-
-Proper Merge request must:
-
-1. Explain in description what it does
-1. Explain which platforms it is run on and which platforms are untested
-1. Contain passing `chefspec` tests
+Please see the [Contributing doc](CONTRIBUTING.md).
 ## Links

gitlab/Vagrantfile

@@ -12,6 +12,11 @@ Vagrant.configure("2") do |config|
   config.vm.box = "precise64"
   config.vm.box_url = "http://files.vagrantup.com/precise64.box"
+  config.vm.provider "vmware_fusion" do |vmware, override|
+    override.vm.box = "precise64_fusion"
+    override.vm.box_url = "http://files.vagrantup.com/precise64_vmware_fusion.box"
+  end
+
   # 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
@@ -43,6 +48,10 @@ Vagrant.configure("2") do |config|
     v.vmx["numvcpus"] = CORES
   end
+  config.vm.provider :parallels do |v, override|
+    v.customize ["set", :id, "--memsize", MEMORY, "--cpus", CORES]
+  end
+  
   # Install the version of Chef by the Vagrant Omnibus
   # version is :latest or "11.4.0"
   # Note:
@@ -72,7 +81,7 @@ Vagrant.configure("2") do |config|
     ]
     # In case chef-solo run is failing silently
     # uncomment the line below to enable debug log level.
-    # chef.arguments = '-l debug'
+    chef.arguments = '-l debug'
   end
 end
@@ -80,3 +89,9 @@ end
 Vagrant.configure("2") do |config|
   config.vm.provision :shell, :path => "./git_login.sh"
 end
+
+# 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 => "./sshd_development.sh"
+end

gitlab/attributes/default.rb

@@ -2,7 +2,7 @@
 if platform_family?("rhel")
   packages = %w{
     libicu-devel libxslt-devel libyaml-devel libxml2-devel gdbm-devel libffi-devel zlib-devel openssl-devel
-    libyaml-devel readline-devel curl-devel openssl-devel pcre-devel git memcached-devel valgrind-devel mysql-devel gcc-c++
+    libyaml-devel readline-devel curl-devel openssl-devel pcre-devel git mysql-devel gcc-c++
     ImageMagick-devel ImageMagick
   }
 else
@@ -18,10 +18,11 @@ default['gitlab']['ruby'] = "2.0.0-p353"
 # GitLab shell
 default['gitlab']['shell_repository'] = "https://github.com/gitlabhq/gitlab-shell.git"
-default['gitlab']['shell_revision'] = "v1.7.9"
+default['gitlab']['shell_revision'] = "v1.8.0"
 # GitLab hq
 default['gitlab']['repository'] = "https://github.com/gitlabhq/gitlabhq.git"
+default['gitlab']['deploy_key'] = "" # Optional. Private key used to connect to private GitLab repository.
 # GitLab shell config
 default['gitlab']['redis_path'] = "/usr/local/bin/redis-cli"
@@ -45,13 +46,18 @@ default['gitlab']['bundle_install'] = "SSL_CERT_FILE=/opt/local/etc/certs/cacert
 default['gitlab']['database_adapter'] = "mysql"
 default['gitlab']['database_password'] = "datapass"
+default['gitlab']['database_user'] = "git"
 default['gitlab']['env'] = "production"
+default['mysql']['server_host'] = "localhost" # Host of the server that hosts the database.
+default['mysql']['client_host'] = "localhost" # Host where user connections are allowed from.
 default['mysql']['server_root_password'] = "rootpass"
 default['mysql']['server_repl_password'] = "replpass"
 default['mysql']['server_debian_password'] = "debianpass"
+
 default['postgresql']['password']['postgres'] = "psqlpass"
+default['postgresql']['server_host'] = "localhost"
 default['postfix']['mail_type'] = "client"
 default['postfix']['myhostname'] = "mail.localhost"
@@ -62,6 +68,8 @@ default['postfix']['smtp_use_tls'] = "no"
 # User
 default['gitlab']['user'] = "git" # Do not change this attribute in production since some code from the GitLab repo such as init.d script assume it is git.
 default['gitlab']['group'] = "git"
+default['gitlab']['user_uid'] = nil # Use to specify user id.
+default['gitlab']['user_gid'] = nil # Use to specify group id.
 default['gitlab']['home'] = "/home/git"
 # GitLab shell
@@ -69,6 +77,16 @@ default['gitlab']['shell_path'] = "/home/git/gitlab-shell"
 # GitLab hq
 default['gitlab']['path'] = "/home/git/gitlab" # Do not change this attribute in production since some code from the GitLab repo such as init.d assume this path.
+default['gitlab']['signup_enabled'] = false
+default['gitlab']['projects_limit'] = 10
+default['gitlab']['oauth_enabled'] = false
+default['gitlab']['oauth_block_auto_created_users'] = true
+default['gitlab']['oauth_allow_single_sign_on'] = false
+default['gitlab']['oauth_providers'] = [] # Example: default['gitlab']['oauth_providers'] = [ { "name": "google_oauth2", "app_id": "YOUR APP ID", "app_secret": "YOUR APP SECRET", "args": "access_type: 'offline', approval_prompt: ''" }, { "name": "twitter", "app_id": "YOUR APP ID", "app_secret": "YOUR APP SECRET" }, { "name":"github", "app_id": "YOUR APP ID", "app_secret": "YOUR APP SECRET" }]
+
+default['gitlab']['extra']['google_analytics_id'] = "" # Example:  "AA-1231231-1"
+default['gitlab']['extra']['sign_in_text'] = "" # Example:  "![Company Logo](http://www.example.com/logo.png)"
+
 # GitLab shell config
 default['gitlab']['repos_path'] = "/home/git/repositories"
@@ -76,14 +94,92 @@ default['gitlab']['repos_path'] = "/home/git/repositories"
 # GitLab hq config
 default['gitlab']['satellites_path'] = "/home/git/gitlab-satellites"
+# Unicorn specific configuration
+default['gitlab']['unicorn_workers_number'] = 2
+default['gitlab']['unicorn_timeout'] = 30
+
 # Setup environments
 if node['gitlab']['env'] == "development"
   default['gitlab']['port'] = "3000"
   default['gitlab']['url'] = "http://localhost:3000/"
+  default['gitlab']['revision'] = "master"
   default['gitlab']['environments'] = %w{development test}
+  default['gitlab']['ssh_port'] = "2222"
 else
   default['gitlab']['environments'] = %w{production}
   default['gitlab']['url'] = "http://localhost:80/"
-  default['gitlab']['revision'] = "6-3-stable"
+  default['gitlab']['revision'] = "6-5-stable" # Must be branch, otherwise GitLab update will run on each chef run
   default['gitlab']['port'] = "80"
+  default['gitlab']['ssh_port'] = "22"
 end
+
+# Nginx ssl certificates
+
+default['gitlab']['ssl_certificate_path'] = "/etc/ssl" # Path to .crt file. If it directory doesn't exist it will be created
+default['gitlab']['ssl_certificate_key_path'] = "/etc/ssl" # Path to .key file. If directory doesn't exist it will be created
+default['gitlab']['ssl_certificate'] = "" # SSL certificate
+default['gitlab']['ssl_certificate_key'] = "" # SSL certificate key
+
+# SMTP email
+default['gitlab']['smtp'] = {
+  :enabled => false,
+  :address => "email.server.com",
+  :port => 456,
+  :username => "smtp",
+  :password => "123456",
+  :domain => "gitlab.example.com",
+  :authentication => "login",
+  :enable_starttls_auto => true
+}
+
+# AWS is disabled by default. If enabled is set to true, bundler will install gems from aws group and use the credentials to populate config/aws.yml
+default['gitlab']['aws'] = {
+  :enabled => false,
+  :provider => 'AWS', # required
+  :aws_access_key_id     => 'yyy', # required
+  :aws_secret_access_key => 'xxx', # required
+  :bucket => 'zzz', # optional
+  :region => 'eu-west-1', # optional, defaults to 'us-east-1'
+  :host     => 's3.example.com', # optional, defaults to nil
+  :endpoint  => 'https://s3.example.com:8080' # optional, defaults to nil
+}
+
+# Monit specific configuration
+default['gitlab']['monitrc']['sidekiq'] = {
+  :pid_path => "#{default['gitlab']['path']}/tmp/pids/sidekiq.pid",
+  :start_timeout => "80", # in seconds
+  :stop_timeout => "40", # in seconds
+  :cpu_threshold => "40", # in %. Assuming our server has two cores, 40% totalcpu means pinning 80% of a single core
+  :cpu_cycles_number => "10",
+  :mem_threshold => "225", # in MB
+  :mem_cycles_number => "10",
+  :restart_number => "5", # Number of consecutive restarts before alerting.
+  :restart_cycles_number => "5" # Number of cycles to monitor for consecutive restarts.
+}
+
+default['gitlab']['monitrc']['unicorn'] = {
+  :pid_path => "#{default['gitlab']['path']}/tmp/pids/unicorn.pid",
+  :mem_threshold => "1000.0", # in MB
+  :mem_cycles_number => "25"
+}
+default['gitlab']['monitrc']['notify_email'] = "monitrc@localhost"
+
+default['gitlab']['ldap']['enabled'] = false
+default['gitlab']['ldap']['host'] = "_your_ldap_server"
+default['gitlab']['ldap']['base'] = "_the_base_where_you_search_for_users"
+default['gitlab']['ldap']['port'] = 636
+default['gitlab']['ldap']['uid'] = "sAMAccountName"
+default['gitlab']['ldap']['method'] = "ssl"
+default['gitlab']['ldap']['bind_dn'] = "_the_full_dn_of_the_user_you_will_bind_with"
+default['gitlab']['ldap']['password'] = "_the_password_of_the_bind_user"
+default['gitlab']['ldap']['allow_username_or_email_login'] = true
+
+default['gitlab']['gravatar'] = true
+
+default['gitlab']['default_projects_features']['issues'] = true
+default['gitlab']['default_projects_features']['merge_requests'] = true
+default['gitlab']['default_projects_features']['wiki'] = true
+default['gitlab']['default_projects_features']['wall'] = false
+default['gitlab']['default_projects_features']['snippets'] = false
+default['gitlab']['default_projects_features']['visibility_level'] = "private"
+

gitlab/attributes/git.rb

 # Git
 default['gitlab']['git']['prefix'] = "/usr/local"
-default['gitlab']['git']['version'] = "1.7.12.4"
+default['gitlab']['git']['version'] = "1.8.4.1"
 default['gitlab']['git']['url'] = "https://github.com/git/git/archive/v#{node['gitlab']['git']['version']}.zip"
 if platform_family?("rhel")

gitlab/doc/development.md

@@ -14,6 +14,22 @@ Make sure to use Vagrant v1.3.x. Do not install Vagrant via rubygems.org as ther
 On OS X you can also choose to use [the (commercial) Vagrant VMware Fusion plugin](http://www.vagrantup.com/vmware) 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](https://github.com/sporkrb/spork). 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](http://www.vmware.com/products/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](https://github.com/jonleighton/spring), 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](development_metal.md).
+
 ### Installation
 `Vagrantfile` already contains the correct attributes so in order use this cookbook in a development environment following steps are needed:
@@ -42,6 +58,12 @@ cd ./cookbook-gitlab
 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:
+
+```bash
+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:
 ```bash
@@ -52,14 +74,19 @@ GITLAB_VAGRANT_MEMORY=2048 GITLAB_VAGRANT_CORES=4 vagrant up
 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 to run tests:
+Once everything is done you can log into the virtual machine and run the tests as the git user:
 ```bash
 vagrant ssh
-sudo su git
 cd /home/git/gitlab/
 bundle exec rake gitlab:test
 ```
@@ -80,7 +107,16 @@ git remote add mine git://github.com/me/gitlabhq.git
 git remote set-url origin git://github.com/me/gitlabhq.git
 ```
-##### Virtual Machine Management
+#### Accessing the application
+
+`http://0.0.0.0:3000/` or your server for your first GitLab login.
+
+```
+admin@local.host
+5iveL!fe
+```
+
+#### Virtual Machine Management
 When done just log out with `^D` and suspend the virtual machine
@@ -120,15 +156,6 @@ Finally, to completely wipe the virtual machine from the disk **destroying all i
 vagrant destroy # DANGER: all is gone
 ```
-#### Done!
-
-`http://0.0.0.0:3000/` or your server for your first GitLab login.
-
-```
-admin@local.host
-5iveL!fe
-```
-
 ### OpenLDAP
 If you need to setup OpenLDAP in order to test the functionality you can use the [basic OpenLDAP setup guide](doc/open_LDAP.md)

gitlab/doc/development_metal.md

+### Development installation on metal (outside a Virtual Machine)
+
+Running Gitlab directly on your machine can make it run considerably faster than inside a virtual machine, possibly making non reasonable wait times (10 minutes to start a test) reasonable (1.5 minutes).
+
+### OS choice
+
+Before doing anything, you have to decide if you will install Gitlab on your existing system, or if you will install a new system dedicated to develop Gitlab.
+
+#### Existing OS
+
+The advantage of installing an existing OS is that you keep all your development programs and configurations untouched, and it is the fastest way to get started.
+
+The downside is that there is a chance that your existing OS setting (e.g. PPAs you added to Ubuntu, binaries you compiled from source) will be incompatible with those required by Gitlab, so if you want to play it safe and avoid hard to track problems, use a dedicated development system.
+
+Furthermore, to install on an existing OS you must be using a supported distribution. It is possible that things will work if you use a non-supported version of a supported system (e.g. Ubuntu 13.10 instead of 12.04), but this adds even further to the risk of incompatibilities.
+
+**Install**
+
+The installation process is the same as a [production install](production.md), the only difference being what you put in the `/tmp/solo.json` configuration file which should instead be:
+
+```bash
+cat > /tmp/solo.json << EOF
+{
+    "gitlab": {
+      "env": "development",
+      "database_adapter": "mysql",
+      "database_password": "a"
+    },
+    "mysql": {
+      "server_root_password": "a"
+    },
+      "run_list": [
+      "gitlab::default"
+    ]
+}
+EOF
+```
+
+#### Dedicated OS
+
+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:
+
+```bash
+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](https://github.com/dosire/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`:
+
+    UUID=<existing_os_uuid> /home/<existing_username>    ext4    defaults    0    0
+
+where you can find the `existing_os_uuid` via `sudo blkid` and `sudo lsblk -f`.
+
+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:
+
+```bash
+sudo apt-get install bindfs
+sudo tee /etc/init/bindfs-gitlab.conf << EOF
+mkdir -p ~/gitlab
+description	"Bindfs mount gitlab for development user."
+
+start on stopping mountall
+
+script
+    bindfs -u $USER -g $USER --create-for-user=git --create-for-group=git /home/git/gitlab /home/$USER/gitlab
+end script
+EOF
+```
+
+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:
+
+```bash
+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
+
+```bash
+cd ~/gitlab
+bundle exec foreman start
+firefox localhost:3000
+```

gitlab/doc/legal/corporate_contributor_license_agreement.md

+You accept and agree to the following terms and conditions for Your present and future Contributions submitted to GitLab.com. Except for the license granted herein to GitLab.com and recipients of software distributed by GitLab.com, You reserve all right, title, and interest in and to Your Contributions.
+
+1. Definitions.
+
+	"You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Agreement with GitLab.com. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
+
+	"Contribution" shall mean the code, documentation or other original works of authorship expressly identified in Schedule B, as well as any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to GitLab.com for inclusion in, or documentation of, any of the products owned or managed by GitLab.com (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to GitLab.com or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, GitLab.com for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."
+
+2. Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to GitLab.com and to recipients of software distributed by GitLab.com a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
+
+3. Grant of Patent License. Subject to the terms and conditions of this Agreement, You hereby grant to GitLab.com and to recipients of software distributed by GitLab.com a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Agreement for that Contribution or Work shall terminate as of the date such litigation is filed.
+
+4. You represent that You are legally entitled to grant the above license. You represent further that each employee of the Corporation designated on Schedule A below (or in a subsequent written modification to that Schedule) is authorized to submit Contributions on behalf of the Corporation.
+
+5. You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others).
+
+6. You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
+
+7. Should You wish to submit work that is not Your original creation, You may submit it to GitLab.com separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".
+
+8. It is your responsibility to notify GitLab.com when any change is required to the list of designated employees authorized to submit Contributions on behalf of the Corporation, or to the Corporation's Point of Contact with GitLab.com.
+
+---------------------------------------
+
+This text is licensed under the [Creative Commons Attribution 3.0 License](http://creativecommons.org/licenses/by/3.0/) and the original source is the Google Open Source Programs Office.
\ No newline at end of file

gitlab/doc/legal/individual_contributor_license_agreement.md

+You accept and agree to the following terms and conditions for Your present and future Contributions submitted to GitLab.com. Except for the license granted herein to GitLab.com and recipients of software distributed by GitLab.com, You reserve all right, title, and interest in and to Your Contributions.
+
+1. Definitions.
+
+	"You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Agreement with GitLab.com. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
+
+	"Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to GitLab.com for inclusion in, or documentation of, any of the products owned or managed by GitLab.com (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to GitLab.com or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, GitLab.com for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."
+
+2. Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to GitLab.com and to recipients of software distributed by GitLab.com a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
+
+3. Grant of Patent License. Subject to the terms and conditions of this Agreement, You hereby grant to GitLab.com and to recipients of software distributed by GitLab.com a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Agreement for that Contribution or Work shall terminate as of the date such litigation is filed.
+
+4. You represent that you are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to GitLab.com, or that your employer has executed a separate Corporate CLA with GitLab.com.
+
+5. You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others). You represent that Your Contribution submissions include complete details of any third-party license or other restriction (including, but not limited to, related patents and trademarks) of which you are personally aware and which are associated with any part of Your Contributions.
+
+6. You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON- INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
+
+7. Should You wish to submit work that is not Your original creation, You may submit it to GitLab.com separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [[]named here]".
+
+8. You agree to notify GitLab.com of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect.
+
+---------------------------------------
+
+This text is licensed under the [Creative Commons Attribution 3.0 License](http://creativecommons.org/licenses/by/3.0/) and the original source is the Google Open Source Programs Office.
\ No newline at end of file

gitlab/doc/monit.md

+### Setting up monit
+
+Monit is an open source utility for managing and monitoring, processes, programs, files, directories and filesystems on a UNIX system. Monit conducts automatic maintenance and repair and can execute meaningful causal actions in error situations.
+
+### Installation
+
+Recipe `gitlab::monit` is not included in the default chef run so in order to use it you will need to add it to the chef run list.
+
+### Usage
+
+There are two defined processes that are being monitored by monit -  sidekiq and unicorn.
+
+#### Sidekiq
+
+If sidekiq is "stuck" and it is using more than 225MB of RAM or if it is using 40% of CPU cycles(for 2 core machine that means 80% of a single core) monit will restart sidekiq.
+If 5 restarts occur, monit will notify via email.
+Attributes needed by default are:
+
+```
+{
+  gitlab_user: "git",
+  gitlab_path: "/home/git/gitlab",
+  sidekiq_pid_path: "/home/git/gitlab/tmp/pids/sidekiq.pid",
+  notify_email: "monitrc@localhost"
+}
+```
+
+#### Unicorn
+
+If unicorn is using more than 1GB of ram or 80% of CPU monit will restart unicorn. It will also notify using notify email.
+
+Attributes needed by default are:
+
+```
+{
+  gitlab_user: "git",
+  gitlab_path: "/home/git/gitlab",
+  unicorn_pid_path: "/home/git/gitlab/tmp/pids/unicorn.pid",
+  notify_email: "monitrc@localhost"
+}
+```
+#### Monit Web interface
+
+Web interface is also enabled and you can use this to have a nice overview of monitored processes. If you need to enable any of the defaults you will have to supply node attributes:
+
+```json
+{
+  "monit": {
+    "web_interface": {
+      "enable": true,
+      "port": 2812,
+      "address": "localhost",
+      "allow": ["localhost", "admin:b1gbr0th3r"]
+    }
+  }
+}
+```
+*Note* above listed attributes are the default so if you are satisfied with them there is no need to supply any attributes to the node.
+
+#### Email settings
+
+Monit will use email client installed on the server by default. If you want to use a different setup you will need to supply node attributes:
+
+```json
+{
+  "monit": {
+      "mail": {
+        "hostname": "localhost",
+        "port": 25,
+        "username": nil,
+        "password": nil,
+        "from": "monit@$HOST",
+        "subject": "$SERVICE $EVENT at $DATE",
+        "message": "Monit $ACTION $SERVICE at $DATE on $HOST,\n\n$DESCRIPTION\n\nDutifully,\nMonit",
+        "security": nil,  # 'SSLV2'|'SSLV3'|'TLSV1'
+        "timeout ": 30
+      }
+    }
+  }
+}
+```
+*Note* above listed attributes are the default so if you are satisfied with them there is no need to supply any attributes to the node.

gitlab/doc/production.md

 ### Production installation with Chef Solo
-This guide details installing a GitLab server with Chef Solo. By using Chef Solo you do not need a decicated Chef Server.
+This guide details installing a GitLab server with Chef Solo.
+By using Chef Solo you do not need a dedicated Chef Server.
 ### Requirements
-* git
-* ruby (>= 1.9.3)
-* rubygems installed.
+Ubuntu 12.04, CentOS 6.4 or RHEL 6.5
 ### Installation
-To get GitLab installed do:
+Configure your installation parameters by editing the `/tmp/solo.json` file.
+Parameters which you will likely want to customize include:
+
+```bash
+cat > /tmp/solo.json << EOF
+{
+  "gitlab": {
+    "host": "example.com",
+    "url": "http://example.com/",
+    "email_from": "gitlab@example.com",
+    "support_email": "support@example.com",
+    "database_adapter": "mysql or postgresql",
+    "database_password": "database password used by the GitLab application",
+    "repository": "clone URL for e.g. GitLab Enterprise Edition; omit this line to use Community Edition",
+    "revision": "branch or tag or SHA1 to install a specific version of GitLab, e.g. 6-4-stable"
+  },
+  "postgresql": {
+    "password": {
+      "postgres": "psqlpass"
+    }
+  },
+  "mysql": {
+    "server_root_password": "mysql root password",
+    "server_repl_password": "mysql replication password; omit this line for a random password",
+    "server_debian_password": "Debian administration password; omit this line for a random password"
+  },
+  "postfix": {
+    "mail_type": "client",
+    "myhostname": "mail.example.com",
+    "mydomain": "example.com",
+    "myorigin": "mail.example.com",
+    "smtp_use_tls": "no"
+  },
+  "run_list": [
+    "postfix",
+    "gitlab::default"
+  ]
+}
+EOF
+```
+
+You only need to keep parameters which need to differ from their default values.
+For example, if you are using `mysql`, there is no need to keep the `postgresql` configuration.
+If you are NOT on Debian/Ubuntu, you can remove `server_debian_password` and if you are not
+planning to use MySQL replication, then you can remove `server_repl_password`.
+
+If you wish to relay mail through a remote SMTP server instead of having Postfix installed you
+can entirely remove the `postfix` section and remove its entry from `run_list`.
+
+First we install dependencies based on the OS used:
+
+```bash
+distro="$(cat /etc/issue | awk ''NR==1'{ print $1 }')"
+case "$distro" in
+  Ubuntu)
+    sudo apt-get update
+    sudo apt-get install -y build-essential git curl # We need git to clone the cookbook, newer version will be compiled using the cookbook
+  ;;
+  CentOS)
+    yum groupinstall -y "Development Tools"
+  ;;
+  *)
+    echo "Your distro is not supported." 1>&2
+    exit 1
+  ;;
+esac
+```
+
+Next run:
 ```bash
-gem install berkshelf
 cd /tmp
 curl -LO https://www.opscode.com/chef/install.sh && sudo bash ./install.sh -v 11.4.4
-git clone https://gitlab.com/gitlab-org/cookbook-gitlab.git /tmp/gitlab
-cd /tmp/gitlab
-berks install --path /tmp/cookbooks
+sudo /opt/chef/embedded/bin/gem install berkshelf --no-ri --no-rdoc
+git clone https://gitlab.com/gitlab-org/cookbook-gitlab.git /tmp/cookbook-gitlab
+cd /tmp/cookbook-gitlab
+/opt/chef/embedded/bin/berks install --path /tmp/cookbooks
 cat > /tmp/solo.rb << EOF
-cookbook_path    ["/tmp/cookbooks/", "/tmp/gitlab/"]
+cookbook_path    ["/tmp/cookbooks/"]
 log_level        :debug
 EOF
-cat > /tmp/solo.json << EOF
-{"gitlab": {"host": "HOSTNAME", "url": "http://FQDN:80/"}, "recipes":["gitlab::default"]}
-EOF
-chef-solo -c /tmp/solo.rb -j /tmp/solo.json
+sudo chef-solo -c /tmp/solo.rb -j /tmp/solo.json
 ```
+
+
 Chef-solo command should start running and setting up GitLab and it's dependencies.
 No errors should be reported and at the end of the run you should be able to navigate to the
-`HOSTNAME` you specified using your browser and connect to the GitLab instance.
-### Usage
-Add `gitlab::default` to the run list of chef-client.
-To override default settings of this cookbook you have to supply a json to the node.
+`gitlab['host']` you specified using your browser and connect to the GitLab instance.
+You should consider removing the `.json` file once you are done with it since
+it contains sensitive information:
+```bash
+rm /tmp/solo.json
+```
+### Enabling HTTPS
+In order to enable HTTPS you will need to provide the following custom attributes:
 ```json
 {
-  "postfix": {
-    "mail_type": "client",
-    "myhostname": "mail.example.com",
-    "mydomain": "example.com",
-    "myorigin": "mail.example.com",
-    "smtp_use_tls": "no"
-  },
-  "postgresql": {
-    "password": {
-      "postgres": "psqlpass"
-    }
-  },
-  "mysql": {
-    "server_root_password": "rootpass",
-    "server_repl_password": "replpass",
-    "server_debian_password": "debianpass"
-  },
   "gitlab": {
-    "host": "example.com",
-    "url": "http://example.com/",
-    "email_from": "gitlab@example.com",
-    "support_email": "support@example.com",
-    "database_adapter": "postgresql",
-    "database_password": "datapass"
-  },
-  "run_list":[
-    "postfix",
-    "gitlab::default"
-  ]
+    "port": "443",
+    "url": "https://example.com/",
+    "ssl_certificate": "-----BEGIN CERTIFICATE-----\nLio90slsdflsa0salLfjfFLJQOWWWWFLJFOAlll0029043jlfssLSIlccihhopqs\n-----END CERTIFICATE-----",
+    "ssl_certificate_key": "-----BEGIN PRIVATE KEY-----\nLio90slsdflsa0salLfjfFLJQOWWWWFLJFOAlll0029043jlfssLSIlccihhopqs\n-----END PRIVATE KEY-----"
+  }
+}
+```
+
+### Cloning GitLab from private repository
+
+By default GitLab is cloned from the public repository.
+If you need to clone GitLab from a private repository (eg. you are maintaining a fork or need to install GitLab Enterprise) you need to specify a deploy key:
+
+```json
+{
+  "gitlab": {
+    "deploy_key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEpAIBAAK\n-----END RSA PRIVATE KEY-----"
+  }
 }
 ```
+
+*Note*: Deploy key is a *private key*.
+=======
+
+*Note*: SSL certificate(.crt) and SSL certificate key(.key) must be in valid format. If this is not the case nginx won't start! By default, both the certificate and key will be located in `/etc/ssl/` and will have the name of HOSTNAME, eg. `/etc/ssl/example.com.crt` and `/etc/ssl/example.com.key`.
+
+### Including multi-line strings in JSON
+
+You can use the following Ruby 1.9 one-liner to output valid JSON for a certificate file or private key:
+
+```bash
+ruby -rjson -e 'puts JSON.dump([ARGF.read])[1..-2]' my_site.cert
+```
+
+### Storing repositories and satellites in a custom directory
+
+In some situations it can be practical to put repository and satellite data on a separate volume.
+Below we assume that the GitLab system user (`git`) will have UID:GID 1234:1234, and that `/mnt/storage` is owned by 1234:1234.
+
+```json
+{
+  "gitlab": {
+    "user_uid": 1234,
+    "user_gid": 1234,
+    "repos_path": "/mnt/storage/repositories",
+    "satellites_path": "/mnt/storage/satellites"
+  }
+}
+```
+
+### Using a proxy server for network access
+
+If you are behind a proxy server, you must ensure that the `http_proxy`
+and `https_proxy` environment variables have been correctly set.
+
+In addition, you need to add the following to the end of your `solo.rb` file:
+
+```ruby
+http_proxy      "https://my-proxy.example.com:8080"
+https_proxy     "https://my-proxy.example.com:8080"
+```
+
+### RHEL
+
+If you are on RHEL 6.4+, `libicu-devel` has been moved to the
+*optional* channel. You must enable the optional channel if you have not
+already done so, see here: https://access.redhat.com/site/solutions/389423.
+
+### Monitoring
+
+Basic monitoring can be [setup with monit](doc/monit.md)

gitlab/git_login.sh

 #!/bin/sh
-if [ ! -f /etc/motd_vagrant ]; then
-  echo 'You are now logged in as the git user that runs GitLab, to get sudo privileges please exit to become the vagrant user' >> /etc/motd_vagrant
-fi
-
-if [ ! -f /etc/motd_git ]; then
-  echo 'You are now logged in as the vagrant user' >> /etc/motd_git
-fi
-if [ ! -f /etc/profile.d/message.sh ]; then
-  echo '#!/bin/sh' >> /etc/profile.d/message.sh
-  echo 'cat /etc/motd_$USER' >> /etc/profile.d/message.sh
+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'
 fi
-cat /home/vagrant/.bashrc | grep 'sudo su git' || echo 'sudo su git' >> /home/vagrant/.bashrc
+cat /home/vagrant/.bashrc | grep --quiet 'sudo su - git' || echo 'sudo su - git' >> /home/vagrant/.bashrc

gitlab/metadata.rb

@@ -4,11 +4,11 @@ maintainer_email 'marin@gitlab.com'
 license          'MIT'
 description      'Installs/Configures GitLab'
 long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
-version          '0.6.3'
+version          '0.6.5'
 recipe "gitlab::default", "Installation"
-%w{ redisio ruby_build postgresql mysql database postfix yum phantomjs magic_shell apt}.each do |dep|
+%w{ redisio ruby_build postgresql mysql database postfix yum phantomjs magic_shell apt monit }.each do |dep|
   depends dep
 end

gitlab/recipes/clone.rb

@@ -5,12 +5,35 @@
 gitlab = node['gitlab']
+# If cloning from a private repository we need to use a deploy key
+# Based on application cookbook: https://github.com/poise/application/blob/v4.1.4/templates/default/deploy-ssh-wrapper.erb
+unless gitlab['deploy_key'].empty?
+  template File.join(gitlab['home'], ".ssh", "deploy-ssh-wrapper.sh") do
+    source "deploy-ssh-wrapper.erb"
+    user gitlab['user']
+    group gitlab['group']
+    mode 0755
+    variables({
+      :path => File.join(gitlab['home'], ".ssh")
+    })
+  end
+
+  file File.join(gitlab['home'], ".ssh", "id_deploy_key") do
+    mode 0600
+    content gitlab['deploy_key']
+    user gitlab['user']
+    group gitlab['group']
+  end
+end
+
 # 6. GitLab
 ## Clone the Source
-git gitlab['path'] do
+git "clone gitlabhq source" do
+  destination gitlab['path']
   repository gitlab['repository']
   revision gitlab['revision']
   user gitlab['user']
   group gitlab['group']
+  ssh_wrapper File.join(gitlab['home'], ".ssh", "deploy-ssh-wrapper.sh") unless gitlab['deploy_key'].empty?
   action :sync
 end

gitlab/recipes/database_mysql.rb

@@ -11,32 +11,34 @@ include_recipe "mysql::server"
 include_recipe "database::mysql"
 mysql_connection = {
-  :host => 'localhost',
+  :host => mysql['server_host'],
   :username => 'root',
   :password => mysql['server_root_password']
 }
 ## Create a user for GitLab.
-mysql_database_user gitlab['user'] do
+mysql_database_user gitlab['database_user'] do
   connection mysql_connection
   password gitlab['database_password']
+  host mysql['client_host']
   action :create
 end
 ## Create the GitLab database & grant all privileges on database
 gitlab['environments'].each do |environment|
-  mysql_database "gitlabhq_#{environment}" do
+  mysql_database "gitlabhq_database" do
+    database_name "gitlabhq_#{environment}"
     encoding "utf8"
     collation "utf8_unicode_ci"
     connection mysql_connection
     action :create
   end
-  mysql_database_user gitlab['user'] do
+  mysql_database_user gitlab['database_user'] do
     connection mysql_connection
     password gitlab['database_password']
     database_name "gitlabhq_#{environment}"
-    host 'localhost'
+    host mysql['client_host']
     privileges ["SELECT", "UPDATE", "INSERT", "DELETE", "CREATE", "DROP", "INDEX", "ALTER", "LOCK TABLES"]
     action :grant
   end

gitlab/recipes/database_postgresql.rb

@@ -10,28 +10,29 @@ gitlab = node['gitlab']
 include_recipe "postgresql::server"
 include_recipe "database::postgresql"
-postgresql_connexion = {
-  :host => 'localhost',
+postgresql_connection = {
+  :host => postgresql['server_host'],
   :username => 'postgres',
   :password => postgresql['password']['postgres']
 }
 ## Create a user for GitLab.
-postgresql_database_user gitlab['user'] do
-  connection postgresql_connexion
+postgresql_database_user gitlab['database_user'] do
+  connection postgresql_connection
   password gitlab['database_password']
   action :create
 end
 ## Create the GitLab database & grant all privileges on database
 gitlab['environments'].each do |environment|
-  postgresql_database "gitlabhq_#{environment}" do
-    connection postgresql_connexion
+  postgresql_database "gitlabhq_database" do
+    database_name "gitlabhq_#{environment}"
+    connection postgresql_connection
     action :create
   end
-  postgresql_database_user gitlab['user'] do
-    connection postgresql_connexion
+  postgresql_database_user gitlab['database_user'] do
+    connection postgresql_connection
     database_name "gitlabhq_#{environment}"
     password gitlab['database_password']
     action :grant

gitlab/recipes/deploy.rb

@@ -22,10 +22,10 @@ include_recipe "gitlab::gems"
 # Configure and install GitLab
 include_recipe "gitlab::install"
-if gitlab['env'] == 'production'
-  # Start GitLab if in production
-  include_recipe "gitlab::start"
+# Start GitLab
+include_recipe "gitlab::start"
+if gitlab['env'] == 'production'
   # Setup and configure nginx
   include_recipe "gitlab::nginx"
 end

gitlab/recipes/gems.rb

@@ -20,7 +20,7 @@ remote_file "Fetch the latest ca-bundle" do
   owner gitlab['user']
   group gitlab['group']
   mode 0755
-  action :create_if_missing
+  action :create
 end
 execute "Update rubygems" do
@@ -32,7 +32,7 @@ template File.join(gitlab['home'], ".gemrc") do
   source "gemrc.erb"
   user gitlab['user']
   group gitlab['group']
-  action :create_if_missing
+  action :create
 end
 ### without
@@ -40,11 +40,10 @@ bundle_without = []
 case gitlab['database_adapter']
 when 'mysql'
   bundle_without << 'postgres'
-  bundle_without << 'aws'
 when 'postgresql'
   bundle_without << 'mysql'
-  bundle_without << 'aws'
 end
+bundle_without << 'aws' unless gitlab['aws']['enabled']
 case gitlab['env']
 when 'production'
@@ -62,10 +61,6 @@ execute "bundle install" do
   cwd gitlab['path']
   user gitlab['user']
   group gitlab['group']
-  action :run
-  not_if { File.exists?(File.join(gitlab['home'], ".gitlab_gems_#{gitlab['env']}")) }
-end
-
-file File.join(gitlab['home'], ".gitlab_gems_#{gitlab['env']}") do
-  action :touch
+  action File.exists?(File.join(gitlab['home'], "Gemfile.lock")) ? :nothing : :run
+  subscribes :run, "git[clone gitlabhq source]", :immediately
 end