CI trigger
What it is
A trigger is the event or schedule that starts a pipeline run. It answers “when should this automation begin?” In Azure Pipelines, common YAML entries are trigger: for pushes, pr: for pull requests, and schedules: for scheduled runs.
Why it exists
Continuous integration should run automatically for relevant changes, without relying on someone to remember a manual run. Triggers scope that automation to the branches, paths, tags, or schedule that matter, which avoids both missed validation and unnecessary runs.
Key ideas
- Azure Pipelines
trigger:— push/CI trigger. If no push trigger is specified, YAML pipelines normally trigger for pushes to all branches unless the organization’s or project’s Disable implied YAML CI trigger setting is enabled.pr:— pull-request trigger; runs when a PR targets matched branches.schedules:— cron-based scheduled builds (cron:,branches:,always:).trigger: nonedisables CI.
- GitHub Actions
on:defines events —push,pull_request,schedule(cron),workflow_dispatch(manual),release, etc.- Branch/path/tag filters via
branches:,paths:,tags:.
- A trigger starts a run; a condition decides whether an already-running job or step runs. They solve different timing decisions.
Northwind example
Northwind’s order-service pipeline triggers on pushes to main and on pull requests targeting main. A path filter avoids rebuilding the service when only its marketing documentation changes. A nightly schedule runs a slower security scan. Inside the run, a deployment job has a condition that limits production deployment to main; that condition does not start the run—it only controls one job after the run has begun.
Exam notes
trigger:handles push CI;pr:handles pull-request validation;schedules:handles time-based runs.- Path and branch filters reduce irrelevant runs but can also accidentally skip required validation if designed too broadly.
- Trigger is distinct from a job or step condition.
Related
pipeline-yaml · azure-pipelines · github-actions
📘 Source: Microsoft Learn — Ci Trigger