.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.
https://cloudaffaire.com/gitlab-ci-yml-part-three-basics-of-rules/
In this blog post, we will discuss .gitlab-ci.yml features tag, allow_failure and when.
Tags:
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
############################################################ ## .gitlab-ci.yml Part Four: tags | allow_failure | when ## ############################################################ ## Prerequisites: GitLab Access Token ## https://cloudaffaire.com/how-to-create-a-gitlab-project-using-api/ ## One CentOs system with internet access ## git, curl and jq package installed ## ------------------------------------ ## Create A GitLab Project To Play With ## ------------------------------------ ## Create a project in GitLab ## GitLab Console => Projects => Your Projects => New Project => PROJECT_ID=$(curl --silent --header "PRIVATE-TOKEN: -XPOST "https://gitlab.com/api/v4/projects?name=cloudaffairecicd&visibility=private&initialize_with_readme=true" | jq '.id') ## Get the ssh clone url for your project ## GitLab Console => Projects => Your Projects => GIT_SSH_CLONE_URL=$(curl --silent --header "PRIVATE-TOKEN: -XGET "https://gitlab.com/api/v4/projects/$PROJECT_ID" | jq -r '.ssh_url_to_repo') ## Clone your GitLab project repository git clone $GIT_SSH_CLONE_URL ## ---- ## tags ## ---- ## Create the pipeline configuration file cd cloudaffairecicd && vi .gitlab-ci.yml --------------------- mygitlabjob_one: script: echo "Hello World" tags: - docker --------------------- :wq ## Push the .gitlab-ci.yml file into GitLab git add . git commit -m "select specific runner based on tag" git push # observe, the pipeline executed with a specific runner having tag docker |
allow_failure:
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
## ------------- ## allow_failure ## ------------- ## Edit the pipeline configuration file cat /dev/null > .gitlab-ci.yml && vi .gitlab-ci.yml --------------------- mygitlabjob_one: stage: test script: - echos "job one will fail" mygitlabjob_two: stage: test script: - echo "job two will pass" mygitlabjob_three: stage: deploy script: - echo "job three will not get executed" --------------------- :wq ## Push the .gitlab-ci.yml file into GitLab git add . git commit -m "deploy stage will be skipped" git push ## Edit the pipeline configuration file cat /dev/null > .gitlab-ci.yml && vi .gitlab-ci.yml --------------------- mygitlabjob_one: stage: test script: - echos "job one will fail" allow_failure: true mygitlabjob_two: stage: test script: - echo "job two will pass" mygitlabjob_three: stage: deploy script: - echo "job three will get executed" --------------------- :wq ## Push the .gitlab-ci.yml file into GitLab git add . git commit -m "deploy stage will be executed" git push |
when:
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).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
## ---- ## when ## ---- ## Edit the pipeline configuration file cat /dev/null > .gitlab-ci.yml && vi .gitlab-ci.yml --------------------- mygitlabjob_one: stage: test script: - echo "this job must be executed manually" when: manual --------------------- :wq ## Push the .gitlab-ci.yml file into GitLab git add . git commit -m "enable manual job execution" git push # observe, the job does not get executed autometically, instaed a button has been provided to manually execute the job ## Delete your project curl --silent --header "PRIVATE-TOKEN: Gats_1gScxGtym6dASB7" \ -XDELETE "https://gitlab.com/api/v4/projects/$PROJECT_ID" | jq '.' cd .. && rm -rf cloudaffairecicd |
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.
https://docs.gitlab.com/ee/README.html
To Get more details on Git you can follow the below links.
https://cloudaffaire.com/category/devops/git/
but why do I care which runner runs my pipeline ? What is the difference between runners that would make me pay attention to this?
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.