Triggers: Push, Pull Request, Schedule, and Manual

In one line

A pipeline doesn't run continuously — it runs in response to a specific, configured event, and choosing the right trigger for the right job is most of what makes a pipeline's behavior actually correct.

0/4 · 0%

Key ideas

01
A TRIGGER is the specific event that causes a pipeline (or a specific job within it) to run — nothing runs on its own schedule by default; every single execution traces back to a configured trigger condition actually being met.
02
on: push runs a pipeline whenever commits are pushed to matching branches — genuinely the most common trigger for a fast build-and-test job, giving quick feedback on every single change as it lands, exactly as Topic 0.4's first example used it.
03
on: pull_request runs specifically when a pull request is OPENED or UPDATED — this is the trigger Git's own course (Phase 4.2, code review) implicitly assumed CI would use: running checks on the PROPOSED change itself, before it's ever merged, giving reviewers an objective signal alongside their own manual review.
04
on: schedule (using the exact same cron syntax Linux's own course covered, Phase 7.3) runs a pipeline at fixed times regardless of any code change — genuinely useful for things that should happen periodically rather than in response to any specific commit: a nightly full regression suite, a weekly dependency-vulnerability scan, a scheduled cleanup job.
05
MANUAL triggers (workflow_dispatch on GitHub Actions, or an equivalent 'Run Pipeline' button on other platforms) let a human explicitly kick off a pipeline on demand, often with custom input parameters — genuinely useful for a deployment that should never happen automatically, requiring a deliberate human action to actually initiate it.
06
Real pipelines commonly combine SEVERAL triggers in one workflow, each serving a genuinely different purpose — fast tests on every push, a fuller suite specifically on pull requests targeting main, and a nightly scheduled run of the slowest, most comprehensive tests that would be impractical to run on every single commit.

Code & diagrams

TriggerPurposesdiagram

Different events, different genuine purposes — not just different syntax for the same thing.

Rendering diagram…

multiple-triggers.ymlmarkdown

One workflow, three genuinely different reasons to run.

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: "0 2 * * *"     # nightly, full regression suite
  workflow_dispatch:          # manual trigger, for on-demand runs

jobs:
  fast-tests:
    if: github.event_name != 'schedule'   # skip the fast job on the nightly run
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: mvn test -Dtest=UnitTests

  full-regression:
    if: github.event_name == 'schedule'   # only run this job on the nightly trigger
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: mvn verify -Dtest=FullRegressionSuite

Explain it without notes

Why would a team configure fast unit tests to run on push, but a slow, comprehensive regression suite to run only on a nightly schedule instead?

Why is a manual trigger (workflow_dispatch) genuinely necessary for some pipelines, rather than just always using push or pull_request?

Practice

Add a schedule trigger to a test workflow (even with a short, frequent test interval like every few minutes, for observing it quickly) and confirm it runs automatically at the configured time without any push or PR involved.

Add a workflow_dispatch trigger to a workflow and manually run it from GitHub's Actions tab UI, confirming it runs on demand with no code change needed to trigger it.

Trade-offs

↔
Combining many trigger types in one workflow file (as this topic's example does) keeps related logic together in one place, but it can make the file genuinely harder to read at a glance, since you need to trace each job's if condition carefully to understand exactly when it actually runs — for a pipeline with genuinely many distinct trigger-based behaviors, splitting into SEPARATE workflow files (one for fast CI, one for nightly regression) is often clearer than one large, conditionally-branching file.

Done when you can

I can name the four main trigger types and a genuine real use case for each.
I understand why fast checks typically run on push/pull_request while slow ones often run on a schedule instead.
I can configure a workflow with a manual (workflow_dispatch) trigger.