www.bitslovers.com Open in urlscan Pro
2607:f8b0:4006:806::2001 Public Scan

Back to summary

Submitted URL:
http://www-bitslovers-com.webpkgcache.com/doc/-/s/www.bitslovers.com/gitlab-ci-rules/
Effective URL:
https://www.bitslovers.com/gitlab-ci-rules/
Submission: On September 11 via manual (September 11th 2024, 11:13:51 pm UTC) from US — Scanned from CA

Form analysis
1 forms found in the DOM

POST https://www.bitslovers.com/wp-comments-post.php

<form action="https://www.bitslovers.com/wp-comments-post.php" method="post" id="ast-commentform" class="comment-form">
  <p class="comment-notes"><span id="email-notes">Your email address will not be published.</span> <span class="required-field-message">Required fields are marked <span class="required">*</span></span></p>
  <div class="ast-row comment-textarea">
    <fieldset class="comment-form-comment">
      <legend class="comment-form-legend"></legend>
      <div class="comment-form-textarea ast-grid-common-col"><label for="comment" class="screen-reader-text">Type here..</label><textarea id="comment" name="comment" placeholder="Type here.." cols="45" rows="8" aria-required="true"></textarea></div>
    </fieldset>
  </div>
  <div class="ast-comment-formwrap ast-row">
    <p class="comment-form-author ast-grid-common-col ast-width-lg-33 ast-width-md-4 ast-float"><label for="author" class="screen-reader-text">Name*</label><input id="author" name="author" type="text" value="" placeholder="Name*" size="30"
        aria-required="true"></p>
    <p class="comment-form-email ast-grid-common-col ast-width-lg-33 ast-width-md-4 ast-float"><label for="email" class="screen-reader-text">Email*</label><input id="email" name="email" type="text" value="" placeholder="Email*" size="30"
        aria-required="true"></p>
    <p class="comment-form-url ast-grid-common-col ast-width-lg-33 ast-width-md-4 ast-float"><label for="url"><label for="url" class="screen-reader-text">Website</label><input id="url" name="url" type="text" value="" placeholder="Website"
          size="30"></label></p>
  </div>
  <p class="comment-form-cookies-consent"><input id="wp-comment-cookies-consent" name="wp-comment-cookies-consent" type="checkbox" value="yes"> <label for="wp-comment-cookies-consent">Save my name, email, and website in this browser for the next time
      I comment.</label></p>
  <p class="form-submit"><input name="submit" type="submit" id="submit" class="submit" value="Post Comment »"> <input type="hidden" name="comment_post_ID" value="3014" id="comment_post_ID">
    <input type="hidden" name="comment_parent" id="comment_parent" value="0">
  </p>
  <p style="display: none;"><input type="hidden" id="akismet_comment_nonce" name="akismet_comment_nonce" value="2517058530"></p>
  <p style="display: none !important;" class="akismet-fields-container" data-prefix="ak_"><label>Δ<textarea name="ak_hp_textarea" cols="45" rows="8" maxlength="100"></textarea></label><input type="hidden" id="ak_js_1" name="ak_js"
      value="1726096423770">
    <script>
      document.getElementById("ak_js_1").setAttribute("value", (new Date()).getTime());
    </script>
  </p>
</form>

Text Content

AWS Learning Kit - 20 Mind Maps + 260 Questions

* AWS Learning Kit
* AWS Audio Book
* Store
* DevOps Menu Toggle
* GitLab
* Terraform
* AWS
* Software Engineering Menu Toggle
* Java
* Maven
* SonarQube
* Linux Menu Toggle
* Commands
* Docker
* Donate
* Submit a Tip!

Main Menu

* Home
* DevOps
* GitLab CI Rules – Change Pipeline Workflow

GITLAB CI RULES – CHANGE PIPELINE WORKFLOW

Leave a Comment / DevOps / By Bits Lovers

Gitlab is a huge DevOps platform that allows us to build any kind of
application, regardless of complexity. But we also need to build our application
according to some rules. In this article, we will talk about the gitlab ci
rules. Those conditions on Gitlab define if the pipeline will be a trigger or
not, according to the conditions specified on the CI/CD configuration file.

GITLAB CI RULES BASICS

Before we start, let’s see the basic operations that we can do with variables to
build our rules.

We can use the equality operators like == and != to compare a variable value
with a given string. Here, single quotes and double quotes can be applied. The
variable can be first, or the string can be first; the order doesn’t matter.

For instance:

* if: $VAR == “some value”
* if: $VAR != “some value”
* if: “some value” == $VAR
* Another especial cases:
* if: $VAR == null # check if the $VAR is undefined
* if: $VARIABLE # check if the $VAR exists

GITLAB CI RULES REGEX VARIABLE

We can apply regex pattern checking on variable values with
the =~ and !~ operators. The regular expressions use the RE2 syntax created by
Google.

Expressions result as true if:

* If the content is found when using =~.
* Matches are not found when using !~.

For instance:

* $VAR =~ /^string.*/
* $VAR1 !~ /^string.*/

By default, the regex is case-sensitive. However, we can use the i flag modifier
to evaluate the regex using case-insensitive.

For instance: /content/i.

HOW TO DETERMINE WHEN A JOB RUN

Gitlab offers different approaches to define when a job runs. The default
behavior is if we don’t specify one rule or condition, all jobs from one
pipeline will be triggered.

Gitlab provides keywords that we can use on the CI/CD configuration file
“.gitlab-ci.yml” to specify a condition. Also, we can combine the usage of those
keywords with Gitlab Variables.

We can determine jobs to run based on the value of the pipeline variables.

To set a job to be included or excluded from particular pipelines, we can use
the following:

* rules
* only
* except

Use needs to set a job to start as soon as the before jobs it relies on finish
running.

Also, we will see the when keyword that we can use to specify if a job will run
manually or not.

GITLAB CI RULES

So, we can use rules to run or skip jobs in pipelines.

Gitlab CI Rules are interpreted in order until the first condition is true. In
other words, when a condition is satisfied, the job is either started or skipped
from the pipeline, relying on the configuration.

Gitlab CI Rules Multiple IF, example:

job:
script: python script.py
rules:
- if: '$CI_COMMIT_REF_NAME == "branch_name"'
when: manual
allow_failure: true
- if: '$CI_COMMIT_REF_NAME == "another_branch"'

YAML
Copy

Let me explain the process described above:

If the pipeline belongs to the “branch_name,” the first rule is valid. So the
job is added to the pipeline, and the attribute:

* when: manual (This is a manual Job, so we need to trigger manually after the
pipeline is created).
* allow_failure: true (the pipeline will continue even if the manual job is not
running)

So, If the pipeline is not from the “branch_name”, it means that the first rule
doesn’t match, and the second rule will be evaluated. Here, if the pipeline
belongs to the “another_branch,” the job will be triggered. We didn’t specify
any attribute for this rule, so the default attributes will be used in place:

* when: on_success (as the default value)
* allow_failure: false (as the default value)

In scenarios where no rules match, the job is not triggered or added to the
pipeline.

In the example above, we use predefined variables from Gitlab. But we can use
our own variables or any other predefined variables. Also, we can add more
Gitlab CI Rules sequentially.

Also, still talking about the previous example, we can quickly invert the logic
by changing the when from manual to never, so we will not add the job to the
pipeline if the branch name matches “branch_name.”

GITLAB CI MANUAL PIPELINE

It’s worth highlighting the importance of manual keywords. We know that Gitlab
is not only about building applications. We can also perform the deployment of
those applications regardless of complexity and Cloud Provider.

For example, our previous article discusses how to build a pipeline to execute a
terraform script.

In pipelines to deploy applications, it’s crucial to set up the pipeline to be
triggered manually because we don’t want to deploy our application to production
if we commit one file every time. After all, maybe we are preparing the script,
and we are not ready to do it.

GITLAB CI COMPLEX PIPELINE

You can utilize all rules keywords in the same rule, like changes and exists.
The rule is interpreted as true only when all used keywords are true.

GITLAB CI RULES CHANGES

For instance:

variables:
MODE: BUILD
build:
script: mvn package -U
rules:
- if: '$MODE == "BUILD"'
changes: # Add the job and set to when:manual if any of the paths bellow match with the modified files.
- src/main/java/*
- src/scripts/*
when: manual

YAML
Copy

In this example above, we are building one java application using Maven.

If any file in src/main/java and in src/script has changed and $MODE == “BUILD,”
then the job runs manually.

GITLAB CI IF FILE EXISTS

Another good feature is triggering a job only if a specific file exists.

variable:
VERSION: v1
job:
script: docker build -t app:$VERSION .
rules:
- exists:
- Dockerfile

YAML
Copy

The job runs if a Dockerfile exists anywhere in the project in the example
above. The exists keyword is an array of file paths, so we can specify more
files to be checked. Important: The paths are relative to the repository
directory ($CI_PROJECT_DIR) and can’t directly link outside it.

GITLAB CI RULES OR

A new feature was added to Gitlab 13.3, where we can create complex expressions
with OR or AND logic using several variables in the same expression. Of course,
we must use parentheses with || (OR) and && (AND) to accomplish that.

compile:
script:
- make && make install
rules:
if: ($CI_COMMIT_BRANCH == "release" || $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH) && $ANOTHER_VARIABLE

YAML
Copy

GITLAB CI RULES EXCEPT

Sometimes, we only focus on a scenario where we don’t want to execute a job. And
to define a rule to skip a job, we can use except keyword.

lint:
script:
- lint src/
except:
variables:
- $CI_PIPELINE_SOURCE == api

YAML
Copy

In the example above, we are skipping the job (lint) when the commit was
triggered using an API call.

Gitlab has a vast collection of predefined variables that we can use in our
pipeline. in our example above, we used the $CI_PIPELINE_SOURCE, where Gitlab
automatically populates its value for us, according to with source from where
the pipeline was triggered.

The possible values of CI_PIPELINE_SOURCE:

API, chat, external, external_pull_request_event, merge_request_event,
parent_pipeline, pipeline, push, schedule, trigger, web, webide.

GITLAB CI RULES IF MERGE REQUEST

To detect if a pipeline was triggered by a Merge Request, we can either use
$CI_PIPELINE_SOURCE == “merge_request_event” or, like the example:

build:
script: docker build -t app:v2 .
only:
refs:
- merge_requests
changes:
- Dockerfile
- scripts/**/*

YAML
Copy

In the example above, combine the keywords only: [merge_requests]. Besides
checking if it’s a merge request, we also look at whether some specific files
were changed to effectively trigger the job.

Post navigation
← Previous Post
Next Post →

www.bitslovers.com Open in urlscan Pro 2607:f8b0:4006:806::2001 Public Scan

Form analysis 1 forms found in the DOM

POST https://www.bitslovers.com/wp-comments-post.php

Text Content

www.bitslovers.com Open in urlscan Pro
2607:f8b0:4006:806::2001 Public Scan

Form analysis
1 forms found in the DOM