Java, Web and Mobile


Getting started with GitLab-CI: Specify jobs and creating output

Continuous Integration

This guide walks you through the process of selecting jobs with respect to different criteria and creating output (artifacts) for later use.

This post is the second part of a series. If you are not yet familiar with GitLab-CI, I suggest to first walk through our getting started guide and then come back.

What you will achieve

Each tagged commit (and only the tagged ones) will provide artifacts which can be downloaded.

What you will need

  • An account on a GitLab-Server (for example
  • A sample program with initial configuration
  • Basic knowledge about the GitLab-CI
  • Git in Version 2.0.0 or later
  • Jdk 1.8
  • Maven 3.0+

Set up

We recommend the output of our previous blog post as starting point. But you can use any maven project in combination with the following GitLab-CI configuration or a similar one.


With the above set up a project is build but no result can be used. By adding the keyword artifacts results will be defined which can be downloaded and therefore the successfull run can be utilized.

Now the results of each build can be downloaded (forever).

Restrict the storage time of artifacts

Although storage costs dropped down, there is no need to infinitely save each build. So an expiration time can be defined.

Exchange data between stages

We could stop here. But the attentive reader may have noticed that we compile our sources twice. In the second job or stage we do not reuse the result of the first one.

In order to fix this we recall that jobs are bundled in stages and each job is run independently. And therefore the order of jobs within a stage is arbitrary. So in general a result of one job cannot be used as input for another one (if they are in the same stages). But for following stages we could reuse artifacts to speed up the process. For this we just have to provide artifacts in the first job or stage as well.

Restrict jobs to branches or tags

Although we are now able to provide artifacts, we may restrict this behaviour to special occasions. For example for releases or other tagged versions. GitLab-CI introduces for this two parameters: ‘only’ and ‘except’. These two allow us to limit when jobs are running.

By name the ‘only’ filter is restricting names of branches and tags for which the job should be run and the ‘except’ filter excludes named branches and tags. Notice that if both are used in a job description, both are inclusive applied.

In addition to regular expression both parameters using some special keywords like tags or branches. For further information see GitLab documentation.

When a job fails

In the above configuration the published job should be skipped if a prior job fails. This behaviour can be specified by the when parameter.

The value on_success is true if all jobs from prior stages succeeded. This is the default configuration and therefore it can be omitted. So our previous configuration already did the job. We just explicit wrote down the behaviour.

But maybe we want to get a mail notification for each broken build on the developed branch and each tagged build. So we add another job with an imagined mail script and the condition on_failure, which is true if at least one job in the prior stages has failed.

Other values for when are always and manually. The last one is useful for manually triggered deployment.


We extended our initial configuration with conditions when to run a job by name of the branches or by tags and even if the previous stages went successfully or not. In addition we have seen how to provide artifacts and how to set a time limit for the file.

Your comment

Your email address will not be published. Required fields are marked *