How to Configure GitLab Pipelines to Run Specific Actions on Non-Master Branches

Discover how to set up your GitLab CI/CD pipelines to execute certain scripts only on non-master branches while maintaining distinct actions for the master branch.
---
This video is based on the question https://stackoverflow.com/q/69766886/ asked by the user 'Andrew Harris' ( https://stackoverflow.com/u/9892615/ ) and on the answer https://stackoverflow.com/a/69767188/ provided by the user 'Tobie van der Merwe' ( https://stackoverflow.com/u/16079040/ ) at 'Stack Overflow' website. Thanks to these great users and Stackexchange community for their contributions.

Visit these links for original content and any more details, such as alternate solutions, latest updates/developments on topic, comments, revision history etc. For example, the original title of the Question was: gitlab - run pipeline for a non-master branch only

Also, Content (except music) licensed under CC BY-SA https://meta.stackexchange.com/help/l...
The original Question post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license, and the original Answer post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license.

If anything seems off to you, please feel free to write me at vlogize [AT] gmail [DOT] com.
---
Going Beyond the Master: Configuring GitLab Pipelines for Non-Master Branches

When migrating from Bitbucket to GitLab, one of the many tasks you may face is configuring your CI/CD pipelines effectively. A common requirement is to run different scripts based on the branch type, specifically for master and non-master branches. This guide will guide you through setting up your GitLab CI/CD pipeline in a way that caters to this need.

The Problem Statement

In your CI/CD setup, the assumption is that you often want to execute different scripts when deploying from the master branch versus from any non-master branch. Here’s a simple breakdown of what you want to achieve:

For the Master Branch

Build Docker Image: Execute a command to build a Docker image.

Push Docker Image: Then, push the Docker image to your Docker registry.

For Non-Master Branches

Build Docker Image: Same as in the master branch, build the Docker image.

Push Docker Image: Again, push the Docker image to your Docker registry.

Update AWS Lambda Function: Use a command to update an AWS Lambda function with the new image.

Solution: Using Rules in Your GitLab CI/CD Configuration

To implement this functionality, you can define rules in your .gitlab-ci.yml file to control the execution of your scripts based on the branch name. Here’s how to achieve that through concise snippets of code.

Step-by-Step Guide

Define the Script for the Master Branch
The following block will define what happens specifically for the master branch.

[[See Video to Reveal this Text or Code Snippet]]

Define the Script for Non-Master Branches
Next, you’ll set up a different block for any branch that is not master:

[[See Video to Reveal this Text or Code Snippet]]

Explanation of the Script

Script Section: Each job defines the commands that will run. In both jobs, the first two commands are similar: building and pushing the Docker image. The non-master job adds an extra command for updating the AWS Lambda function.

Rules Section: The rules define the conditions under which each job will run. GitLab uses these conditions to determine if a job should be executed in a CI/CD pipeline based on the current branch. In the master job, the check is for equality ($CI_COMMIT_BRANCH == "master"), while the non-master job checks for inequality ($CI_COMMIT_BRANCH != "master").

Conclusion

Setting up your GitLab CI/CD pipelines to differentiate actions between master and non-master branches can greatly enhance your deployment strategy. By implementing the provided .gitlab-ci.yml configurations with respective rules, you can ensure that your applications are built and deployed efficiently while minimizing the risk of deploying unfinished or misconfigured code from non-master branches.

Feel free to adapt this structure further based on your project needs, and happy coding as you transition to GitLab!