What Are CI/CD Pipeline Triggers and How Do They Work?
Learn the types of CI/CD pipeline triggers — push, scheduled, manual, and upstream — and when to use each for safe, fast automation.
Expected Interview Answer
A pipeline trigger is the event that causes a CI/CD pipeline to start running automatically — most commonly a Git push or pull request, but also a scheduled time (cron), a manual button click, an upstream pipeline finishing, or an external webhook — and choosing the right trigger type controls when and how often expensive automation actually runs.
Push and pull-request triggers are the default for continuous integration: every commit to a branch or every PR update kicks off build and test automatically, giving fast feedback on the exact change being reviewed. Scheduled (cron) triggers run a pipeline on a timer regardless of code changes — useful for nightly full test suites, dependency vulnerability scans, or periodic infrastructure drift checks that do not need to run on every commit. Manual triggers require a human to click “run,” typically gating higher-risk actions like production deploys or destructive operations behind explicit approval. Pipeline (or upstream) triggers chain pipelines together, so pipeline B only starts after pipeline A succeeds — common for a deploy pipeline that only runs after the build-and-test pipeline passes. Webhook triggers let external systems (a registry push, a third-party service, an issue tracker event) kick off a pipeline programmatically. A well-designed pipeline mixes trigger types deliberately: fast automatic triggers for feedback loops, scheduled triggers for periodic maintenance work, and manual gates for anything with real production risk.
- Push/PR triggers give fast, automatic feedback on every change
- Scheduled triggers run expensive checks without slowing every commit
- Manual triggers add a human approval gate before risky actions
- Upstream/webhook triggers let pipelines and external systems chain reliably
AI Mentor Explanation
A push trigger is like a net session starting automatically the moment a player arrives at the ground — no one has to call anyone, it just begins. A scheduled trigger is like a fitness test the whole squad takes every Monday morning regardless of who is around that day. A manual trigger is like the captain personally calling for a risky declaration only when they decide to press the button, never automatically. An upstream trigger is like the second-string squad's session only starting once the main squad's session has finished and cleared the nets.
Step-by-Step Explanation
Step 1
Pick the trigger type for the job
Push/PR for fast feedback, scheduled for periodic maintenance, manual for risky actions, upstream for chained pipelines.
Step 2
Define the trigger condition
Scope by branch, path filters, cron expression, or the specific upstream pipeline/status required.
Step 3
Configure the automation to fire
The CI/CD platform listens for the event (webhook, scheduler, API call) and starts the pipeline run.
Step 4
Add manual gates for risk
Require explicit human approval before triggers that touch production or irreversible operations proceed.
What Interviewer Expects
- Ability to name and distinguish push/PR, scheduled, manual, and upstream/webhook triggers
- Understanding of why scheduled triggers exist separately from push triggers
- Awareness that manual triggers act as approval gates for risky operations
- Knowledge of chaining pipelines via upstream/downstream triggers
Common Mistakes
- Running every expensive check on every push instead of scheduling some periodically
- Not gating production deploys behind a manual approval trigger
- Confusing a scheduled trigger with a push trigger that just happens to run often
- Forgetting path/branch filters, causing pipelines to fire on irrelevant changes
Best Answer (HR Friendly)
“A pipeline trigger is just what causes automation to actually run — a code push for fast feedback, a schedule for nightly checks, a manual click for anything risky like a production deploy, or one pipeline finishing and kicking off the next. Choosing the right trigger for each job means we get fast feedback where it matters and human approval where the risk is real, without slowing everything down.”
Code Example
on:
push:
branches: [main]
pull_request:
branches: [main]
schedule:
- cron: "0 2 * * *" # nightly full test suite at 2am
workflow_dispatch: {} # manual trigger, requires a human click
jobs:
deploy:
if: github.event_name == "workflow_dispatch"
environment: production
runs-on: ubuntu-latest
steps:
- run: echo "Deploying to production after manual approval"Follow-up Questions
- When would you use a scheduled trigger instead of a push trigger?
- How would you gate a production deploy behind a manual approval trigger?
- How do upstream/downstream pipeline triggers help decouple build and deploy?
- What risks come from over-triggering expensive pipelines on every commit?
MCQ Practice
1. Which trigger type is best suited for a nightly full regression test suite?
A scheduled trigger runs on a timer independent of code changes, ideal for periodic expensive checks like nightly regression suites.
2. Why is a manual trigger commonly used for production deploys?
Manual triggers require someone to deliberately approve the action, reducing the risk of an accidental production change.
3. What does an upstream (pipeline) trigger enable?
Upstream triggers chain pipelines so a downstream pipeline (e.g. deploy) only starts once its upstream dependency (e.g. build-and-test) succeeds.
Flash Cards
What is a pipeline trigger? — The event that starts a CI/CD pipeline run — push, schedule, manual click, or upstream pipeline success.
When is a scheduled trigger preferred over push? — For periodic, expensive checks (nightly suites, scans) that should not run on every commit.
Why use a manual trigger for production? — It adds a required human approval gate before a risky, irreversible action.
What is an upstream trigger? — A trigger that starts a pipeline only after another pipeline has already succeeded.