Choosing Between 'push' and 'pull_request' Triggers for GitHub Actions CI

The Integration Dilemma: Validating Source vs. Result

When configuring Continuous Integration (CI) in GitHub Actions, developers often struggle with whether to trigger tests on a push or a pull_request. Choosing the wrong trigger can lead to "false positives," where tests pass on a feature branch but fail immediately after merging into the main branch due to integration conflicts.

The core difference lies in what GitHub Actions actually tests. A push trigger runs against the specific commit you uploaded. A pull_request trigger runs against a merge commit—a temporary preview commit that GitHub creates to simulate what the code will look like after it is merged into the target branch.

Comparison of Trigger Behaviors

Feature	on: push	on: pull_request
Execution Target	The exact commit pushed to the branch.	A simulated merge commit (Source + Target).
Primary Goal	Verify the current state of a branch.	Verify the result of the integration.
Branch Protection	Cannot natively block a PR merge.	Can be required as a status check to block merges.
Secret Access	Full access to repository secrets.	Limited access (none for PRs from forks).
CD Trigger	Ideal for triggering deployments.	Not suitable for deployments.

Evaluating the Trade-offs

The Case for pull_request

Use pull_request when your primary goal is gatekeeping. Because it tests the merge commit, it catches errors caused by the target branch moving forward while the feature branch was being developed. If you use push, you might see a green checkmark on your branch, but the merge might still break the build because the target branch changed in the interim.

The Case for push

Use push for post-merge validation and Continuous Deployment (CD). Once a PR is merged, the pull_request event ends. To ensure the main branch remains stable and to trigger a production deployment, a push trigger on the default branch is required.

The Redundancy Risk

Defining both push and pull_request for the same branch often leads to double-billing. If you push a commit to a branch that has an open PR, GitHub may trigger both workflows simultaneously. This consumes GitHub Actions minutes without providing additional safety.

Implementation: The Hybrid Strategy

The most robust engineering pattern is to use pull_request for feature validation and push exclusively for the default branch (e.g., main). This ensures a "fail-fast" mechanism during review and a "final seal" of quality before deployment.

Create this configuration in .github/workflows/ci.yml:

name: CI Pipeline

on:
  # Trigger on PRs to main to validate the merge result
  pull_request:
    branches: [ main ]
  # Trigger only on pushes to main for final validation/CD
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Tests
        run: npm test # Replace with your test command

Operational Requirements

• Permissions: The user creating the workflow file must have write access to the repository.
• Placeholders: Replace npm test with your specific test suite (e.g., pytest, mvn test).
• Risk: If your tests require API keys stored in GitHub Secrets, pull_request triggers from external contributors (forks) will fail because secrets are not passed to forks for security reasons.

Verifying the Setup

To ensure the logic is functioning as intended, perform these three checks:

1. PR Validation: Open a pull request from a feature branch to main. Verify that the action triggers and labels the PR with a status check.
2. Merge Validation: Merge the PR. Verify that a second workflow run starts specifically for the push event on the main branch.
3. Isolation Check: Push a commit to a feature branch that does not have an open PR. Verify that no workflow is triggered, saving your action minutes.

Rollback Procedure

If the workflow triggers too frequently or blocks merges incorrectly, revert the on: section to a single trigger (e.g., on: push) and commit the change to the default branch to restore previous behavior.