What are the common ways a CI/CD pipeline run gets started, and how do they differ in what they cost and what feedback they give?

## Why interviewers ask this Trigger choice decides how much compute a single merge consumes and how quickly a developer learns they broke something. Both numbers are directly visible to a team lead, so the taxonomy comes up early. ## The taxonomy **Push to a branch.** The default. Fires on every commit reaching any matching branch. Cost scales with commit rate, not merge rate — a developer who pushes eight work-in-progress commits pays for eight runs unless superseded runs are cancelled. Feedback goes to one author. **Pull request / merge request.** Fires when a change proposal is opened, updated or reopened. This is the run that gates review and merge, so it is the one that must be fast. Two subtleties matter: many platforms build the *merge result* (your branch merged into the target) rather than your branch tip, which is why a green proposal can go red after merge if the target moved; and a proposal from an untrusted fork is a different trust context, which is why fork runs are usually restricted. **Tag or release creation.** Fires when a version tag appears. This is the trigger that should build and publish release artifacts, because a tag is the only trigger whose identity is a version rather than a moment in time. Bounded frequency: a few per week. **Scheduled / cron.** Fires on a timer with no commit involved. Its whole justification is detecting change you did not cause — a newly disclosed CVE in a pinned dependency, a rebuilt base image, an expiring certificate or token, a flaky test that only shows up over many repetitions. It is also the only trigger that burns money on days when nobody ships, and the only one with nobody watching the result, so a scheduled pipeline needs an alert route or it silently rots. **Manual / on-demand.** A human presses a button, usually with parameters (which environment, which version). Cost is a person's attention rather than compute, and that is exactly why it is used for expensive or irreversible work. **Upstream pipeline / dependency completion.** One pipeline finishes and starts another, typically across repositories: a shared library publishes, and consumers rebuild against it. Powerful and dangerous — the amplification factor is real. One commit to a base library with forty consumers is forty runs, and if those consumers trigger each other you can build a cascade that outruns your runner pool. **API / webhook / external event.** A script, a chat command, a ticket transition or another system calls in. Useful for glue and for scheduled work owned outside the repository; it needs authentication and rate-thinking like any other endpoint, and it is the trigger most likely to be forgotten in an audit of "what can start a production deploy". ## The cost model A rough per-merge figure is worth carrying in your head: ``` cost per merge ≈ (commits pushed per change × push-run minutes) + (PR updates × PR-run minutes) + (share of tag/scheduled/upstream runs attributable to the change) ``` The first two terms dominate almost everywhere, and they are also where the two classic wastes live: - **Double-firing.** Push and PR triggers both match the same commit on a proposal branch, so every update runs the suite twice. Scoping the push trigger to long-lived branches only is the standard fix. - **No superseding.** Six pushes in ten minutes produce six full runs, five of which nobody will look at. ## Matching trigger to work | Trigger | Who is waiting | What belongs on it | |---|---|---| | PR update | the author, right now | fast checks: lint, unit, build | | Push to main | the team | the full gate that protects the trunk | | Tag | a release manager | build and publish the artifact, exactly once | | Schedule | nobody | slow suites, drift and dependency checks | | Manual | an operator | deploys, migrations, expensive one-offs | | Upstream | a downstream owner | rebuild and re-verify against a new dependency | ## Two failure modes worth naming **The pipeline that ran nothing.** Trigger conditions are filters, and a filter that matches nothing produces a run that is technically successful and tested nothing — dangerous when a merge gate treats "no run" or "skipped" as "passed". **The trigger loop.** A pipeline that commits something back to the repository — a version bump, a formatted file, a lockfile — re-triggers itself on push. Every platform has a way to stop it; every platform also has a team that discovered the loop from its bill.