Make sure to edit the config file to match your setup:
# Change **YOUR_SERVER_IP** and **YOUR_SERVER_FQDN**
# to the IP address and fully-qualified domain name
# of your host serving GitLab CI
sudo editor /etc/nginx/sites-enabled/gitlab_ci
## Check your configuration
sudo nginx -t
## Start nginx
sudo /etc/init.d/nginx start
# 9. GitLab OAuth2 application
Go to the admin area of GitLab, to the `Application` section. Create an application for the GitLab CI
For callback URL use: `http://ci.example.com/user_sessions/callback` if you use http, or `https://ci.example.com/user_sessions/callback` if you use https.
When `app_id` and `app_secret` are generated add them to the GitLab CI config:
```
production:
gitlab_server:
url: 'http://gitlab.example.com'
app_id: XXXXXX
app_secret: XXXXXX
```
# 10. Runners
Now you need Runners to process your builds.
Checkout the [Gitlab Runner section](https://about.gitlab.com/gitlab-ci/#gitlab-runner) to install it
# Done!
Visit YOUR_SERVER for your first GitLab CI login.
You will be asked to authorize with your GitLab credentials.
- Red Hat Enterprise Linux (please use the CentOS packages and instructions)
- Scientific Linux (please use the CentOS packages and instructions)
- Oracle Linux (please use the CentOS packages and instructions)
For the installations options please see [the installation page on the GitLab website](https://about.gitlab.com/installation/).
### Unsupported Unix distributions
- OS X
- Arch Linux
- Fedora
- Gentoo
- FreeBSD
### Non-Unix operating systems such as Windows
GitLab CI is developed for Unix operating systems.
GitLab CI does **not** run on Windows and we have no plans of supporting it in the near future.
Please consider using a virtual machine to run GitLab CI.
## Ruby versions
GitLab requires Ruby (MRI) 2.0 or 2.1
You will have to use the standard MRI implementation of Ruby.
We love [JRuby](http://jruby.org/) and [Rubinius](http://rubini.us/) but GitLab CI needs several Gems that have native extensions.
### Memory
You need at least 1GB of addressable memory (RAM + swap) to install and use GitLab CI!
## Unicorn Workers
It's possible to increase the amount of unicorn workers and this will usually help for to reduce the response time of the applications and increase the ability to handle parallel requests.
For most instances we recommend using: CPU cores + 1 = unicorn workers.
So for a machine with 2 cores, 3 unicorn workers is ideal.
For all machines that have 1GB and up we recommend a minimum of three unicorn workers.
If you have a 512MB machine with a magnetic (non-SSD) swap drive we recommend to configure only one Unicorn worker to prevent excessive swapping.
With one Unicorn worker only git over ssh access will work because the git over HTTP access requires two running workers (one worker to receive the user request and one worker for the authorization check).
If you have a 512MB machine with a SSD drive you can use two Unicorn workers, this will allow HTTP access although it will be slow due to swapping.
To change the Unicorn workers when you have the Omnibus package please see [the Unicorn settings in the Omnibus GitLab documentation](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/unicorn.md#unicorn-settings).
## Supported web browsers
- Chrome (Latest stable version)
- Firefox (Latest released version and [latest ESR version](https://www.mozilla.org/en-US/firefox/organizations/))
- Safari 7+ (known problem: required fields in html5 do not work)
Since version 5.1 GitLab CI is shipping as part of the GitLab omnibus package. This guide describes how to migrate GitLab CI from a source installation to an Omnibus package.
### 1. Update GitLab
Update GitLab CI manually to the version that you will install using the omnibus package (at least 7.11). Follow the update [manual for installation from sourse](update/README.md)
This command will create a backup file in the tmp folder
(`/home/gitlab_ci/gitlab_ci/tmp/backups/*_gitlab_ci_backup.tar.gz`). You can read more in the [GitLab CI backup/restore documentation](https://gitlab.com/gitlab-org/gitlab-ci/blob/master/doc/raketasks/backup_restore.md)
### 2. Install a packaged GitLab CI
This process is described in the [instruction for enabling GitLab CI](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/gitlab-ci/README.md)
### 4. Restore backup
Put backup file to directory `/var/opt/gitlab/backups`.
A backup creates an archive file that contains the database and builds files.
This archive will be saved in backup_path (see `config/application.yml`).
The filename will be `[TIMESTAMP]_gitlab_ci_backup.tar.gz`. This timestamp can be used to restore an specific backup.
You can only restore a backup to exactly the same version of GitLab CI that you created it on, for example 7.10.1.
*If you are interested in the GitLab backup please follow to the [GitLab backup documentation](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/raketasks/backup_restore.md)*
```
# use this command if you've installed GitLab CI with the Omnibus package
# Fog storage connection settings, see http://fog.io/storage/ .
connection:
provider:AWS
region:eu-west-1
aws_access_key_id:AKIAKIAKI
aws_secret_access_key:'secret123'
# The remote 'directory' to store your backups. For S3, this would be the bucket name.
remote_directory:'my.s3.bucket'
multipart_chunk_size:104857600
```
If you are uploading your backups to S3 you will probably want to create a new
IAM user with restricted access rights. To give the upload user access only for
uploading backups create the following IAM profile, replacing `my.s3.bucket`
with the name of your bucket:
```json
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"Stmt1412062044000",
"Effect":"Allow",
"Action":[
"s3:AbortMultipartUpload",
"s3:GetBucketAcl",
"s3:GetBucketLocation",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:ListBucketMultipartUploads",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource":[
"arn:aws:s3:::my.s3.bucket/*"
]
},
{
"Sid":"Stmt1412062097000",
"Effect":"Allow",
"Action":[
"s3:GetBucketLocation",
"s3:ListAllMyBuckets"
],
"Resource":[
"*"
]
},
{
"Sid":"Stmt1412062128000",
"Effect":"Allow",
"Action":[
"s3:ListBucket"
],
"Resource":[
"arn:aws:s3:::my.s3.bucket"
]
}
]
}
```
## Storing configuration files
Please be informed that a backup does not store your configuration and secret files.
If you use an Omnibus package please see the [instructions in the readme to backup your configuration](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md#backup-and-restore-omnibus-gitlab-configuration).
If you have a cookbook installation there should be a copy of your configuration in Chef.
If you have an installation from source:
1. please backup `config/secrets.yml` file that contains key to encrypt variables in database,
but don't store it in the same place as your database backups.
Otherwise your secrets are exposed in case one of your backups is compromised.
1. please consider backing up your `application.yml` file,
1. any SSL keys and certificates,
1. and your [SSH host keys](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079).
## Restore a previously created backup
You can only restore a backup to exactly the same version of GitLab CI that you created it on, for example 7.10.1.
You may also want to set a limited lifetime for backups to prevent regular
backups using all your disk space. To do this add the following lines to
`/etc/gitlab/gitlab.rb` and reconfigure:
```
# limit backup lifetime to 7 days - 604800 seconds
gitlab_ci['backup_keep_time'] = 604800
```
NOTE: This cron job does not [backup your omnibus-gitlab configuration](#backup-and-restore-omnibus-gitlab-configuration).
## Known issues
If you’ve been using GitLab CI since 7.11 or before using MySQL and the official installation guide, you will probably get the following error while making a backup: `Dumping MySQL database gitlab_ci_production ... mysqldump: Got error: 1044: Access denied for user 'gitlab_ci'@'localhost' to database 'gitlab_ci_production' when using LOCK TABLES` .This can be resolved by adding a LOCK TABLES permission to the gitlab_ci MySQL user. Add this permission with:
```
$ mysql -u root -p
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, LOCK TABLES ON `gitlab_ci_production`.* TO 'gitlab_ci'@'localhost';
__GitLab CI 5.4 requires GitLab 7.5 or higher and GitLab CI Runner v5__
### 1. stop CI server
sudo service gitlab_ci stop
### 2. Switch to your gitlab_ci user
```
sudo su gitlab_ci
cd /home/gitlab_ci/gitlab-ci
```
### 3. Get latest code
```
git fetch
git checkout 5-4-stable
```
#### Redis config
If you have `config/resque.yml` file - please update it with recent `config/resque.yml.example`
### 4. Install libs, migrations etc
```
# For MySQL users
bundle install --without postgres development test --deployment
# For Postgres users
bundle install --without mysql development test --deployment
# Run migrations
bundle exec rake db:migrate RAILS_ENV=production
```
### 5. Update config
GitLab CI 5.4 and above make use of the OAuth2 protocol for authentication with GitLab. This means that after updating GitLab (CI),
you need to create an OAuth2 application in GitLab admin area, which gives you the APP_ID and APP_SECRET.
For callback URL use: `http://ci.example.com/user_sessions/callback` if you use http, or `https://ci.example.com/user_sessions/callback` if you use https.
You will have to add APP_ID and APP_SECRET to the GitLab CI config, as such:
With this release we are bumping the GitLab CI version to 7.8 in order to be on par with the current GitLab version and
to avoid naming confusion.
__GitLab CI 7.8 requires GitLab 7.8 or higher and GitLab CI Runner v5__
### 1. stop CI server
sudo service gitlab_ci stop
### 2. Switch to your gitlab_ci user
```
sudo su gitlab_ci
cd /home/gitlab_ci/gitlab-ci
```
### 3. Get latest code
```
git fetch
git checkout 7-8-stable
```
#### Redis config
If you have `config/resque.yml` file - please update it with recent `config/resque.yml.example`
### 4. Install libs, migrations etc
```
# For MySQL users
bundle install --without postgres development test --deployment
# For Postgres users
bundle install --without mysql development test --deployment
# Run migrations
bundle exec rake db:migrate RAILS_ENV=production
```
### 5. Update config
GitLab CI 5.4 and above make use of the OAuth2 protocol for authentication with GitLab. This means that after updating GitLab (CI),
you need to create an OAuth2 application in GitLab admin area, which gives you the APP_ID and APP_SECRET.
For callback URL use: `http://ci.example.com/user_sessions/callback` if you use http, or `https://ci.example.com/user_sessions/callback` if you use https.
You will have to add APP_ID and APP_SECRET to the GitLab CI config, as such:
__GitLab CI 7.9 requires GitLab 7.9 or higher and GitLab CI Runner v5__
### 1. stop CI server
sudo service gitlab_ci stop
### 2. Switch to your gitlab_ci user
```
sudo su gitlab_ci
cd /home/gitlab_ci/gitlab-ci
```
### 3. Get latest code
```
git fetch
git checkout 7-9-stable
```
#### Redis config
If you have `config/resque.yml` file - please update it with recent `config/resque.yml.example`
### 4. Install libs, migrations etc
```
# Install nodejs dependency:
sudo apt-get install nodejs
# For MySQL users
bundle install --without postgres development test --deployment
# For Postgres users
bundle install --without mysql development test --deployment
# Run migrations
bundle exec rake db:migrate RAILS_ENV=production
```
### 5. Update config
GitLab CI 5.4 and above make use of the OAuth2 protocol for authentication with GitLab. This means that after updating GitLab (CI),
you need to create an OAuth2 application in GitLab admin area, which gives you the APP_ID and APP_SECRET.
For callback URL use: `http://ci.example.com/user_sessions/callback` if you use http, or `https://ci.example.com/user_sessions/callback` if you use https.
You will have to add APP_ID and APP_SECRET to the GitLab CI config, as such:
Since when we start this `gitlab_ci` service, the document `db/schema.rb` is shown always as modified for git, you could even do like this, **if and only if**, you are sure you only have that modification:
