You are currently viewing .gitlab-ci.yml Part Four – Basics Of Tags Allow Failure When

.gitlab-ci.yml Part Four – Basics Of Tags Allow Failure When

.gitlab-ci.yml Part Four – Basics Of Tags Allow Failure When

Hello Everyone

Welcome to CloudAffaire and this is Debjeet.

In the last blog post, we have discussed how to control the pipeline job executing with rules.

In this blog post, we will discuss .gitlab-ci.yml features tag, allow_failure and when.


tags is used to select specific Runners from the list of all Runners that are allowed to run this project. During the registration of a Runner, you can specify the Runner’s tags, for example ruby, postgres, development. tags allow you to run jobs with Runners that have the specified tags assigned to them. Tags are also a great way to run different jobs on different platforms, for example, given an OS X Runner with tag osx and Windows Runner with tag windows.


allow_failure allows a job to fail without impacting the rest of the CI suite. The default value is false, except for manual jobs. When enabled and the job fails, the job will show an orange warning in the UI. However, the logical flow of the pipeline will consider the job a success/passed, and is not blocked. Assuming all other jobs are successful, the job’s stage and its pipeline will show the same orange warning. However, the associated commit will be marked “passed”, without warnings.


when is used to implement jobs that are run in case of failure or despite the failure. when can be set to one of the following values:

  • on_success – execute job only when all jobs from prior stages succeed (or are considered succeeding because they are marked allow_failure). This is the default.
  • on_failure – execute job only when at least one job from prior stages fails.
  • always – execute job regardless of the status of jobs from prior stages.
  • manual – execute job manually (added in GitLab 8.10).
  • delayed – execute job after a certain period (added in GitLab 11.14).

Hope you enjoyed this article. In the next blog post, we will continue our discussion .gitlab-ci.yml.

To get more details on GitLab you can follow the below link.

To Get more details on Git you can follow the below links.


This Post Has 2 Comments

  1. Avatar
    Alex Lerner

    but why do I care which runner runs my pipeline ? What is the difference between runners that would make me pay attention to this?

  2. Avatar
    Brian Davidson

    If you’re using a runner to deploy to production, and that runner is running on the production server you want to make sure the deployment job runs on *that* server, not a build server. Likewise, you probably don’t want to be building code on your production server.

Leave a Reply