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
The restriction, which forced the use of only locally available images, was lifted as of March 2022. Newly, the faculty GitLab CI will try to download locally unavailable images automatically when starting a task that uses the image.
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
Docker image tags are not static, ie.
X:3.0 is only a symbolic name for a version of the image, and the repository administrator may change the image pointed to at any time. The versioning of images and the meaning of the versions themselves depend on the administrators of the individual Docker repositories, but
in general it is advisable to follow the principles of semantic versioning.
If possible, prefer images in the most general major version possible (eg prefer
X:3.5.0 ) so that your project has an image with security patches and bug fixes in the software used.
However, we do not
recommend using it
latest for important projects. This symbolic tag
usually points to the latest stable version of the image, but may move to a newer version that is not backward compatible without warning.
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.
The Container Registry service gives users the ability to save images to the Docker project, which can then be used in CI or other projects.
The images may not be related to the content of the project. However, you will probably have i
Dockerfile and other dependencies, so we recommend that you create a repository for these files that keeps the current version of the image.
The Container Registry can be connected on the machine
gitlab.fi.muni.cz a port
Turn on the serviceIn the project in which you want to maintain your own images, turn on
Settings → General → Visibility, project features, permissions → Container Registry .
Limit the number of tagsImages in the Container Registry usually take up a lot of space. Frequent tag changes can quickly deplete disk space, so turn on automatic cleaning for your project:
In the Settings → Packages & Registries settings, turn on the Clean up image tags option. We also recommend that you change the Keep the most recent: setting to 5 tags per image name .
Image accessAccess to images is generally governed by the access rights to the parent project:
- Private - Only project members
- Internal - Only persons logged in to GitLab FI
- Public - No restrictions
Creating an image
Create the image locally in your own Docker instance. The name of the image to be placed in the GitLab Container Registry must start with the domain and port in the format
gitlab.fi.muni.cz:5050 , and continue on to the project.
For example, for a project
https://gitlab.fi.muni.cz/NAMESPACE/PROJECT.git therefore, images with shape names can be created
If you are satisfied with the image, you can upload it to the Container Registry:
docker login --username ‹LOGIN› gitlab.fi.muni.cz:5050 docker push gitlab.fi.muni.cz:5050/NAMESPACE/...
In the first command instead
‹LOGIN› use your faculty login. The command asks for a password when run; enter
faculty password or
GitLab access token .
You can see the file for an example
Makefile in the repository
Use in GitLab CI
The new image can be used both in your own Docker instance and in GitLab CI / CD tasks. Only in settings
image: specify the path to your own image.
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.