Small research proves that GitLab can be easily expanded.

Let’s start with creating the runner (in different systems they may appear as workers or agents) for CI. Again it depends much on the expand speed of the workers.

First we need Linux-machine with installed Docker on it. You can make a script, which will install the Docker on the PC automatically. If it is regarding the Digital Ocean, there is a possibility to have Docker preinstalled. If it is regarding the Linode, than some problems can occur with it. First thing is the problem with supporting of AUFS and there is a need of another core. We’ll prepare the script for the core mounting and publish it soon. Anyway, it is necessary to restart the server and select in the administrative bar GRUB2 to activate a new core.

Then we install Docker. Actually it can be done with another script. The only question will appear with core replacement and selection of GRUB2 in the console. Otherwise this process could be completely  automated. You can also try to create a script in the Linode (its native), that installs Docker, but they were created 2 years ago and using an old-dated product is not a big pleasure.

After the Docker is set successfully installed we can start with the GitLab runner https://docs.gitlab.com/runner/install/docker.html

Basically we run only 2 commands:

docker run -d --name gitlab-runner --restart always \
 -v /srv/gitlab-runner/config:/etc/gitlab-runner \
 -v /var/run/docker.sock:/var/run/docker.sock \
 gitlab/gitlab-runner:latest
 
docker exec -it gitlab-runner gitlab-runner register

In another words if the Docker installation is automated, the installation of new runners doesn’t take much time. After the runner is added it appears in the list with a mentioned tag. Important: Docker-runners should contain docker tag.

We add 2 files to the project:

gitlab-ci.yml

image: ruby:2.3
 
services:
 - postgres:9.5
 
before_script:
 - apt-get update -qq
 - apt-get install -y -qq nodejs
 - cp ci/database.yml config/database.yml
 - gem install bundler --no-ri --no-rdoc
 - bundle install --without production development
 - bundle exec rake db:setup
 - bundle exec rake db:migrate
 
rspec:
 script:
 - bundle exec rspec
 only:
 - master
 tags:
 - docker
 
variables:
 RAILS_ENV: test
 POSTGRES_DB: dbname
 POSTGRES_USER: username
 POSTGRES_PASSWORD: ""

Let’s make it clear:

image: ruby:2.3 this image is needed for the test runner deployment. Download it once and then it creates containers at each new test run.

services – these are the additional containers. As we test postgres, we chose the postgres base accordingly. Native downloading of it is also possible, but it takes additional time.

before_script – it is all the actions we take prior to launching the tests.

rspec –  it is actually the name of job (it doesn’t matter much in current task). It runs on the branch Master only and with the runner, which contains docker tag.

variables – are the exported data . POSTGRES_* are the variables for postgres service.

Being in the runner with root rights, allows us to set, add and change everything. That’s a benefit of Docker’s containers.

Now let’s move to the second file.

ci/database.yml

test:
 adapter: postgresql
 pool: 5
 timeout: 5000
 host: postgres
 database: dbname
 user: username

As we can see the settings are the same as in :

variables:
 RAILS_ENV: test
 POSTGRES_DB: dbname
 POSTGRES_USER: username
 POSTGRES_PASSWORD: ""

I have to mention one thing regarding postgres host: Docker links 2 containers, and that means that the way to find the container with postgres is written in the runner’s.

123.34.23.123 postgres

Finally, we need to create properly gitlab-ci.yml and enjoy the results.

  Be Gera-Successful