Pipeline Triggers: The 'If This, Then That' of CI/CD

Why it exists

Without triggers, CI/CD pipelines would need to be run manually. This defeats the purpose of automation, which is to provide fast, consistent feedback. Triggers connect events in your development lifecycle, like pushing code, directly to the automated processes that build, test, and deploy it.

The mental model

Think of a pipeline trigger as a sensor with a specific instruction. A "push to main branch" sensor detects that event and says "run the deployment pipeline." A "new pull request" sensor detects its event and says "run the validation build." Each trigger is a rule that connects a cause (a repository event) to an effect (a pipeline run).

How it works

You define triggers in your pipeline configuration file, typically a YAML file. The syntax specifies the event type (CI, PR, schedule) and any filters. For example, a CI trigger might watch only the main and develop branches. When your CI/CD platform detects an event that matches a trigger's definition, it executes the pipeline. Common trigger types are Continuous Integration (on push), Pull Request (on PR creation/update), scheduled (on a timer), and pipeline completion (when another pipeline finishes).

When to use it

Use triggers to automate any repetitive task tied to your codebase. Use CI triggers to build and run unit tests on every push to a feature branch. Use PR triggers to run extensive integration tests and code quality checks before a merge. Use scheduled triggers for tasks like nightly builds, security scans, or generating daily reports.

When not to use it

Avoid overly broad or sensitive triggers. Don't set up a trigger that automatically deploys every push from any branch to production. Also, be mindful of "trigger storms" where one action can set off a cascade of many pipeline runs, especially with pipeline completion triggers. For pipelines with high cost or significant impact, consider making the trigger manual or adding a human approval step.

One canonical example

In a YAML pipeline file, a Continuous Integration (CI) trigger that only runs for pushes to the main branch would look like this: trigger: - main. To disable CI triggers entirely and only run the pipeline manually or via other triggers, you would use: trigger: none. To run a pipeline for any pull request targeting the main branch, you would specify: pr: - main.