Your tasks: Task automation using GitLab CI/CD

What is GitLab CI/CD?

Description

GitLab CI/CD is the tool used in GitLab hosted projects to run CI/CD pipelines. It is the equivalent of Github Actions for GitHub-hosted repositories. If you are interested in migrating your GitHub Actions “actions” into GitLab CI/CD, you can follow the GitLab-dedicated article on Github Actions migration.

Why would you set up a GitLab CI/CD pipeline? It can help you automate:

• running unit tests
• building your application
• building a Docker container for your application
• deploying your software’s documentation
• deploying and generating a package for your software others can install and reuse
• checking your software’s dependencies

Considerations

To create and run your first pipeline:

• For self-hosted GitLab instances - ensure you have runners available to run your jobs. If your repository is hosted on gitlab.com, you do not need to do anything as GitLab provides instance runners for you.
• Create a .gitlab-ci.yml file at the root of your repository. This file, written with YAML syntax, defines the pipelines and jobs you want to run.
• Commit and push this file to your repository.
• Go to the Pipelines tab in your GitLab repository to see the pipeline run. This dashboard provide you the list of the pipelines run for your project, with the workflow of the different stages. You can access the different jobs by clicking on the Stages elements to have more information about their respective status.

Using pre-builts components from the Gitlab CI/CD Catalog

The Gitlab CI/CD Catalog provides a list of components to use in your own pipeline. Most of these provides a README describing how you can use them and how to configure them for your own purpose.

Solutions

You can follow GitLab CI/CD Quick Start tutorial and the more advanced tutorial.

GitLab also provides some typical examples based on your programmation language and type of project.

Example of .gitlab-ci.yml

stages:
    - build
    - deploy

build-job-name1:
    stage: build
    script:
        - echo "Starting job 1"

build-job-name2:
    stage: build
    script:
        - echo "Starting job 2"

deploy-job-name:
    stage: deploy
    script:
        - echo "Deploy"

This will create a pipeline with two stages build and deploy. The stage build is composed of two independant jobs that will be run in parallel if you have enough runners. The deploy stage will be run after build stage is finished. This is defined by the stages: list. By default, if a job fails, the other jobs in that stage are run but not the one in the following stages.

In the next part of the example, a new job, named build-job-name1, is defined. The mandatory fields are: stage and script. The first one is used to associate this job to a stage defined in the stageskey. script is defining the script to be run by this job. It can be composed by multiple commands separated as a list.

The rest of the file defines two other jobs build-job-name2 and deploy-job-name2. The stage named build has 2 jobs that are run in paralell. If you need the output of one job to run another one, you should put them in separate stages. In our example case, the job deploy_job-name could use artefacts generated by jobs in the stage build.

Note: the example above is a dummy example that just presents the structure of the gitlab-ci.yml file. In practice, it only prints somes messages to simulate scripts.

References

• Official GitLab CI/CD documentation
• GitLab CI/CD examples - list of commonly used .gitlab-ci.yml files
• GitLab CI/CD syntax

Related pages

Your tasks

Continuous Integration and Continuous Delivery/Deployment

How can you use CI/CD in software development?

Your tasks

Task automation using GitHub Actions

How to set up GitHub Actions on software repositories for task automation

Tools and resources on this page

Tom François

Contributor

CNRS-LAPP

How to cite this page

Tom François, "Task automation using GitLab CI/CD". everse.software. http://everse.software/RSQKit/task_automation_gitlab_ci_cd .