translated by Google

Machine-translated page for increased accessibility for English questioners.

Page in original, Czech language.

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

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: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

Version selection

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 place 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.

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.

If you do not set up cleanup and the project artifacts use GitLab disk space, administrators will be deleted.

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.

Container Registry

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 5050 .

Service settings

  • Turn on the service

    In 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 tags

    Images 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 access

    Access 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
    In addition, access can be restricted by setting the above from Everyone with access to Only project members .

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

  • gitlab.fi.muni.cz:5050/NAMESPACE/PROJECT:TAG
  • gitlab.fi.muni.cz:5050/NAMESPACE/PROJECT/IMAGE:TAG
  • gitlab.fi.muni.cz:5050/NAMESPACE/PROJECT/NAME/IMAGE:TAG

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 https://gitlab.fi.muni.cz/xlacko1/pb173-perl-image .

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.