GitLab FI

GitLab Continuous Integration

GitLab Continuous Integration (CI) is used to automate some development tasks in the repository, most often for automatic unit testing. You can use GitLab CI configure your own physical or virtual machine (see virtualization Stratus.FI ). In addition, a teaching machine can also be used gitlab-ci.fi.muni.cz .

Summary

Faculty gitlab-ci.fi used by the official GitLab Runner with container insulation in service Docker . After starting a new task (eg after git push GitLab Runner asks Docker to create a new container from the image that is declared in the repository in the file .gitlab-ci.yml . The repository is cloned into the container and the tasks described in the mentioned file are started. When finished, the container is canceled and the result is returned to GitLab, which displays it in the CI / CD section.

Project configuration for gitlab-ci.fi.muni.cz

Read first introductory information for using GitLab CI / CD . You will also need documentation for .gitlab-ci.yml .

Image selection

Docker is configured not to automatically install all required images, but to use only those locally available. This prevents over-installation of different versions of the images, which would quickly fill the disk capacity of the machine.

A list of images available for the faculty GitLab CI can be found at Faculty administration application .

The image used is declared in the configuration .gitlab-ci.yml as the key value image . The format is either REPOSITORY:TAG or REPOSITORY (The default tag is then used latest ). If you do not enter an image, it will be used alpine:latest .

image: maven:latest

If possible, use branded images latest or at least the most general version possible (e.g. 3-jdk-8 place 3.5.0-jdk-8 ). If the images are updated, the older versions will be deleted if there is free disk space.

Brand settings

To avoid burdening tasks from repositories that have their own CI set up, it accepts gitlab-ci.fi tasks only from those projects that are marked with the brand shared-fi , which can be set as follows:

• in Settings → General → Permissions, enable the Pipelines option if it is not already enabled
• in settings .gitlab-ci.yml add tag shared-fi to each target, eg:

  build:
    tags:
      - shared-fi

Artifact settings

For the projects he creates artifacts , we recommend setting the CI so that GitLab automatically cleans it up when a newer one is created.

First, make sure that GitLab preserves the last artifact in the project:
Project → Settings → CI / CD → Artifacts → check Keep artifacts from most recent successful jobs

Pak do .gitlab-ci.yml add a setting that sets the life of the artifacts to a very small value (less than 2 hours, such as 10 minutes). Set this for each task JOB .
Thanks to the setting above, the last artifact will be preserved even after the end of its service life.

‹JOB›:
  artifacts:
    …
    expire_in: 10 minutes

Samples

You can look at the project in the faculty GitLab FI unix/ci-examples for examples of CI configuration for simple projects.

Installing additional or custom images

Request to install additional images or versions at unix@fi.muni.cz where you specify what you will use the image for.

If you want to install your own or customized image, please include the application Dockerfile and all the necessary files to build the image. Administrators build and install the image into Docker.

Common problems and solutions

If you encounter a Job is stuck error after configuring the project, you probably did not specify a tag in the job configuration shared-fi . Check the settings as described above.