← Back to libraryQuestion 232 of 273
🔧CI/CDIntermediate

Triggering Strategy (PR vs Merge vs Nightly vs Manual)

📌 Definition:

A triggering strategy decides which tests run when — matching the cost and duration of a test set to the event that triggers it — so pull requests get fast feedback, merges get fuller validation, and expensive suites run on a schedule rather than blocking every change.

📖 Detailed Explanation:

Not every test should run on every event. Running the entire cross-browser, cross-environment suite on every push makes PR feedback slow and expensive; running only a tiny smoke set before production is reckless. The strategy layers triggers by cost/risk. On pull_request: fast, high-signal checks (lint, unit, API, a smoke subset of E2E) so developers get feedback in minutes. On merge to main: a fuller regression run since the change is now integrated. On schedule (nightly): the exhaustive matrix — all browsers, all environments, long-running performance/visual suites — where duration doesn't block anyone. On workflow_dispatch (manual): on-demand runs for hotfix verification or re-running a flaky suite. Path filters refine this further (only run E2E when app code changes, not for docs-only PRs). The interview theme is matching test cost to the moment it delivers value.

🔑 Key Points:
  • Match test cost/duration to the trigger — don't run everything on every push
  • PR: fast high-signal checks (lint, unit, API, smoke E2E) for minute-scale feedback
  • Merge to main: fuller regression once the change is integrated
  • Nightly schedule: exhaustive matrix, performance/visual, long suites
  • Manual (workflow_dispatch) for hotfix verification; path filters skip irrelevant runs
🌍 Real-World Example:

A team runs lint+unit+API+smoke-E2E on every PR (about 4 minutes), the full regression on merge to main, and the exhaustive 6-browser × 3-environment matrix plus performance tests nightly at 2 AM. Developers get fast PR feedback, main stays well-validated, and the heavy matrix never blocks a merge.

📎 Code Example:
on:
  pull_request:            # fast feedback
    paths: ['src/**', 'tests/**']   # skip docs-only changes
  push:
    branches: [main]        # fuller run after merge
  schedule:
    - cron: '0 2 * * *'     # nightly exhaustive suite
  workflow_dispatch: {}     # manual hotfix verification

jobs:
  quick:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps: [ { uses: actions/checkout@v4 }, { run: 'npm ci && npm run test:smoke' } ]
  full:
    if: github.event_name != 'pull_request'
    runs-on: ubuntu-latest
    steps: [ { uses: actions/checkout@v4 }, { run: 'npm ci && npm run test:full' } ]
🎯 Scenario-Based Interview Question:

Scenario: Every PR currently runs the entire suite — all browsers, all environments, performance tests — taking 45 minutes, and developers are blocked waiting. Leadership won't accept 'less testing'. How do you redesign triggers without reducing overall coverage?