Setting up Gitlab CI for Elixir/Phoenix on your VPS

Gitlab is a great development tool, getting better with every release. They give you access to their new-ish pipelining features on Gitlab.com for free. However, I wanted to setup the Gitlab Runner (this is what executes your CI build) on my own VPS using Docker. Gitlab makes this very easy to install, but the documentation is spread out when it comes to setup and execution. I thought an all in one document showing all the steps would be helpful to the community.

I am hoping this post will help out others looking to run their Elixir/Phoenix application tests through the CI pipeline using their own VPS.

All commands were executed on my VPS as the root user. If you are logged in as a user that has sudo access, you will need to prepend all commands with sudo.

Prerequisites: A VPS or similar server (virtualbox, docker, …)

 Setup the Gitlab Runner

 Run on your VPS

Install docker

Install Gitlab Runner Repository

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh

Install Gitlab Runner

apt-get install gitlab-ci-multi-runner

Login to Gitlab.com and navigate to the project you want to use the runner for. Open the project Settings -> CI/CD Pipelines section.

settings-ci-cd-pipelines.png

You will then see the Specific Runners section which contains the URL and key to use to setup your runner.

registration-token.png

Register the runner

gitlab-ci-multi-runner register

When asked which executor to use, type in docker. You will need to provide the default docker image to use, I used elixir:1.4. Also I set the runner to not be project specific, and to only run tagged builds. The tag I am using for the runner is elixir.

 Configure your Elixir application

Create a .gitlab-ci.yml file, at the root of your repo, with the following contents.

image: elixir:1.4

services:
  - postgres:9.6.2

variables:
  POSTGRES_DB: project_test
  POSTGRES_USER: runner
  POSTGRES_PASSWORD: “[email protected]”

stages:
  - test

before_script:
  - mix local.hex –force
  - mix local.rebar –force
  - mix deps.get
  - MIX_ENV=test mix ecto.create
  - MIX_ENV=test mix ecto.migrate

unit-testing:
  stage: test
  script:
    - MIX_ENV=test mix test

tags:
    - elixir

 Database configuration

The last step before any tests can be ran is to update the config/test.exs file. The database name, username, password, and host should match what was set in the .gitlab-ci.yml file. We didn’t explicitly set the host in that file because it is handled for us. The hostname would be postgres.

# Configure your database (config/test.exs)
config :project, Project.Repo,
  adapter: Ecto.Adapters.Postgres,
  username: "runner",
  password: "[email protected]",
  database: "project_test",
  hostname: "postgres",
  pool: Ecto.Adapters.SQL.Sandbox

 Finishing up

Push the branch to Gitlab, and open the Pipeline tab for the project. You should see the tests running for your branch. The page doesn’t appear to automatically update, a refresh may be needed to see latest pushes. If the tests pass, you should see something similar:

ci-run-results.png

Gitlab also has badges build in to spice up your README.md or project site.

badge.png

 Updates

 
2
Kudos
 
2
Kudos

Now read this

Install Rescuetime on Solus Linux

If you use a linux distribution which cannot install .deb or .rpm packages, Rescuetime appears to be unusable. Solus Linux cannot install either of those packages, and the developer I reached out to at Rescuetime didn’t quite know why I... Continue →