Are you tired of spending hours manually testing and deploying your code? Say goodbye to tedious processes and welcome the world of GitLab CI/CD Rules.
This powerful configuration is here to revolutionize your keyword workflow, making it seamless and efficient.
Whether you’re a developer, a project manager, or a team lead, GitLab CI/CD Rules will ensure your pipelines are evaluated correctly.
With GitLab CI/CD Rules, you can automate your code testing and deployment, saving you precious time and effort.
No more endless back-and-forths between teammates, worrying about manual errors, or untested code getting into the default branch.
This game-changing feature allows you to define a set of rules that trigger automated actions whenever specific keywords are mentioned.
Imagine the possibilities of having your tests run automatically, deployments executed promptly, and notifications sent to relevant team members, all with just a single push to your repository.
Achieving perfection in your keyword workflow has never been easier. GitLab CI/CD Rules offers an intuitive and customizable platform that adapts to your team’s specific needs.
It’s literally just a file (or file paths).
This flexible tool not only enhances collaboration and productivity but also ensures the seamless flow of your development, minimizing bottlenecks and maximizing efficiency.
(P.S: I think GitLab CI/CD is MUCH better than GitHub)
Where Are Rules Within GitLab?
Rules are everywhere within GitLab, and if you’ve recently started using GitLab or recently have been introduced in Gitlab, you’re going to need them.
HOWEVER
To understand job rules, you must first understand variables in GitLab CI.
Variables come from various sources, such as API requests, manual entries by the user, scheduled pipelines, manual jobs, and more.
They are used in the CI engine – and when you run a job or pipeline, they appear as environment variables.
However, there are some things called Predefined Variables. Predefined variables are defined by GitLab and are populated by GitLab.
You can read from them, but you shouldn’t write to them.
There are many predefined variables; while you don’t need to know about them, some are handy to reference and use in rules.
Let’s jump in and make you an expert in the GitLab UI and other pipeline configurations.
Understanding Variables in GitLab CI
To comprehend rules in GitLab CI, it is crucial to have a good understanding of variables.
Variables in GitLab CI originate from various sources, including manual entry by the user, API requests, configuration at the project, group, or instance level, generation in jobs in previous stages, direct input from the CI configuration, or GitLab itself.
These variables are used in two different places: the CI engine within GitLab and the jobs themselves, where they appear as environment variables.
It can be overwhelming to deal with many variables from different sources. Some of these variables are predefined and defined by GitLab and are populated by GitLab.
There are about 110 predefined variables, most of which are unnecessary for everyday use, but it is beneficial to know about them and reference them occasionally.
Predefined variables can be helpful when setting up rules.
It is also essential to understand that several events can trigger a pipeline to run, including a new commit, a new branch, or a new tag.
Using rules to detect how your pipeline and jobs are being run is crucial to prevent the same job from running twice.
Rules are the solution to this problem. The basic outline of rules includes the job name, the word “rules,” the “if” clause, and the script.
Breaking Down CI Rules (Keywords)
The “if” clause can reference variables; for the most part, the “if” clauses will reference variables.
The “only” and “except” blocks are no longer available in jobs, and you have to use variables for everything now.
The essential components of rules are clauses, operators, results, and when options. The clauses include “if,” “changes,” and “exists.”
The “if” clause is the one that is used the most, and it uses some function or expression using variables. The operators operate on variables, including “equals,” “not equals,” “equals to,” and “not equals to.”
The result of the clause is almost always “when.” The “when” clause can be “always,” “never,” “on success,” “on failure,” “manual,” or “delayed.”
If there is no “when” clause, the default is “when on success” and “allow failure false.”
A job is added to the pipeline if the rule matches and has “on success,” “delayed,” or “always” in the “when” clause.
If no rules match, the last clause is assumed to be “when never.” A job is not added to the pipeline if no rules match and there is no “when on success,” “when later,” or “when always” at the end.
If a rule matches and has “when never” as the attribute, the job will not run.
I can not explain to you how many times this rule has blocked a job run when a merge request is created (even on the default branch!)
Predefined Variables (Example Workflow To Run A Job)
Simply put, Predefined variables are defined by GitLab and populated by GitLab.
While users should not write to these variables, they can read from them. These predefined variables can be found in the reference material and documentation, and while about 90% of them are not necessary, some can be advantageous when setting up rules.
It is also essential to understand the various events that can trigger a pipeline to run, such as new commits, branches, tags, manual API calls, or scheduled runs.
Jobs and pipelines can detect how they were triggered, and it is crucial to use rules to prevent duplicate jobs from running.
Here is an example `.gitlab-ci.yml` file that uses some predefined GitLab keywords, which could be used as a merge request pipeline or a branch pipeline:
stages:
- build
- test
- deploy
variables:
IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
build:
stage: build
script:
- docker build -t $IMAGE_TAG .
- docker push $IMAGE_TAG
test:
stage: test
script:
- docker run $IMAGE_TAG npm test
deploy:
stage: deploy
script:
- kubectl apply -f kubernetes/deployment.ymlThis configuration file defines three stages: `build`, `test`, and `deploy`.
The `build` stage builds a Docker image and pushes it to the GitLab Container Registry using the predefined variables `$CI_REGISTRY_IMAGE` and `$CI_COMMIT_SHORT_SHA`.
The `test` stage runs the tests inside a Docker container using the previously built image.
Finally, the `deploy` stage deploys the application to a Kubernetes cluster using the `kubectl` command.
Avoiding Duplicate Pipelines With Rules
We need to use rules in our GitLab CI configuration to avoid duplicate pipelines.
Rules allow us to specify conditions under which a job should run based on variables from different sources. These variables can be predefined by GitLab or generated by jobs in previous stages.
When pipelines run, different events can trigger them, such as new commits, branches, or tags. Using rules to detect how pipelines and jobs are being run is vital to prevent the same job from running twice.
To use rules, we need to define them in our job configuration. The syntax for rules is as follows:
job_name:
rules:
- if: condition
when: always/never/on_success/on_failure/manual/delayed
allow_failure: true/false
start_in: duration
- if: condition
when: always/never/on_success/on_failure/manual/delayed
allow_failure: true/false
start_in: duration
...(add more)
script:
- command1
- command2
...(add more)The if clause is the most critical part of the rules and allows us to specify conditions using variables.
We can use different operators, such as ==, !=, =~, &&, and ||, to combine variables and create complex conditions.
The when clause specifies when the job should run based on the pipeline status.
As we’ve said before, you can use different options, such as always, never, on_success, on_failure, manual, and delayed.
The allow_failure option allows us to specify whether the job can fail without affecting the pipeline status.
The start_in option allows us to specify a duration to delay the job start.
It’s important to note that if we don’t specify a when clause, the default value is on_success.
If we don’t specify any rules, the job will run in all cases where the previous stages have passed.
In summary, by using rules in our GitLab CI configuration, we can prevent duplicate pipelines and improve the efficiency of our jobs.
We can specify conditions using variables and different operators and control when the job should run based on the pipeline status.
Some Other CI/CD Articles
Here at enjoymachinelearning.com we have a few other articles that goes in-depth about CI/CD.
Here are a few of those:
- GitLab CI/CD PyTest Tutorial For Beginners
- .NET CI/CD In Gitlab
- Timeout CICD GitLab
- Jenkins PIpeline vs GitLab Pipeline
- Gitlab CICD Artifacts
- MLOps vs. Data Engineer
