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 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
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 (The default tag is then used
latest ). If you do not enter an image, it will be used
If possible, use branded images
latest or at least the most general version possible (e.g.
3.5.0-jdk-8 ). If the images are updated, the older versions will be deleted if there is free disk space.
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
shared-fito each target, eg:
build: tags: - shared-fi
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
.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
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
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
unixnCpPcpK_c@fiB=Yvrsh=N.munixdscW_9CC.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.