Mastering Manual and Master-Triggered Builds in GitLab CI
GitLab CI/CD is a powerful tool for automating your development workflow, allowing you to run builds, tests, and deployments seamlessly. But sometimes, you need more control over when a build should run. This article explores how to configure your GitLab CI pipeline to run a job either manually or only when changes are made to the master branch.
The Problem: Balancing Automation and Control
Imagine you have a complex build process that you want to run regularly, but only under specific conditions. You might want to trigger a build manually for a major release, while also ensuring automatic builds on the master branch for continuous integration. The challenge lies in achieving this flexibility within the GitLab CI framework.
The Solution: Leveraging trigger and only keywords
GitLab CI provides two powerful keywords: trigger and only, which allow for fine-grained control over job execution. Let's examine a practical example:
stages:
- build
build_job:
stage: build
script:
- echo "Building the application..."
trigger: manual
only:
- master
This code defines a job named build_job that belongs to the build stage. The trigger: manual setting ensures that the job is only triggered manually. Furthermore, the only: master clause restricts the job's execution to only pushes to the master branch.
Understanding the Functionality
-
trigger: manual: This setting enables you to manually trigger the build. It's ideal for scenarios requiring human intervention, such as when a major release is ready for testing. -
only: master: This clause specifies the branches that can trigger the job. In our case, thebuild_jobwill run only when changes are pushed to themasterbranch.
Adding More Flexibility with rules
For more complex scenarios, you can use the rules keyword to define multiple conditions that must be met for a job to run.
build_job:
stage: build
script:
- echo "Building the application..."
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
when: never
- if: '$CI_COMMIT_REF_NAME == "master"'
when: always
- if: '$CI_TRIGGER_SOURCE == "manual"'
when: always
This example prevents the build_job from running for merge request events while enabling it for manual triggers and pushes to the master branch.
Advantages of Using Manual and Master-Triggered Builds
- Controlled Release Management: By manually triggering builds for major releases, you can ensure thorough testing and validation before pushing to production.
- Continuous Integration: Automatic builds on the
masterbranch promote continuous integration by detecting integration issues early. - Flexibility and Customization: The combination of
triggerandonlykeywords provides granular control over your build processes, allowing for tailored automation based on specific requirements.
Conclusion
Understanding how to leverage trigger, only, and rules within GitLab CI empowers you to create flexible build pipelines that cater to your specific workflow needs. By combining manual triggering and automated execution for different branches, you can streamline your development process while maintaining control over critical build events.
