Triggering on Push: Automating Your CI/CD Pipeline

Previously in this course, we covered Anatomy of a Workflow and Understanding Runners and Jobs to build the structural foundation of our automation. Up until now, you’ve likely been triggering your workflows manually via the GitHub UI. While that's great for testing, it’s not true Continuous Integration.

To achieve real CI, your pipeline must react to your work, not the other way around. Today, we’ll move from manual intervention to event-driven automation using the on: push trigger.

Moving Beyond Manual Triggers

In DevOps, the "Continuous" in CI/CD implies that integration happens automatically whenever a developer submits code. If you rely on clicking a "Run workflow" button, you introduce human error—you might forget to run the tests, or worse, you might forget to check the results.

By using triggers, we tell GitHub Actions to listen for specific events in your repository. When a git push event occurs, GitHub scans your .github/workflows/ directory, finds the configuration, and kicks off the job immediately. This provides the tight feedback loop necessary to catch regressions early, similar to how we use Git Bisect to isolate bugs in history, but here we prevent them from entering the repository in the first place.

Configuring the 'on: push' Trigger

In your existing YAML file, the on: block likely contains workflow_dispatch:. This is what enables the manual "Run workflow" button. To automate this, we replace or augment it with push.

The Configuration Structure

Open your workflow file (e.g., .github/workflows/ci.yml) and update the on section as follows:

YAML
name: CI Pipeline

on:
  push:
    branches:
      - main
  workflow_dispatch:

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

Why specify branches?

By adding branches: - main, you ensure the pipeline only runs when you push to your production-ready branch. This prevents unnecessary compute costs when you are pushing experimental branches or local feature branches that aren't ready for integration yet.

Hands-on Exercise: Observe the Automation

Let's put this into practice. Follow these steps to verify your new automated trigger:

1. Modify the Workflow: Update your .github/workflows/ci.yml file with the on: push configuration shown above.
2. Commit the Change: Save the file and run git add ., git commit -m "Add push trigger", and git push origin main.
3. Check the UI: Navigate to the "Actions" tab in your GitHub repository. You should see a workflow run already in progress (or completed) without you having touched the "Run workflow" button.
4. Verify the Source: Click on the run and look at the "Trigger" metadata. It should say "Push" instead of "Workflow dispatch."

Common Pitfalls

Even for seasoned engineers, these traps can cause headaches:

• Syntax Errors in YAML: YAML is whitespace-sensitive. Ensure your indentation for the branches list is correct; otherwise, the trigger will silently fail to fire.
• Infinite Loops: Avoid triggering workflows on pushes that the workflow itself makes (like automated version bumps). If you need to push from a workflow, use a specific GITHUB_TOKEN and ensure your trigger doesn't cause a recursive loop.
• Forgetting to Push: It sounds trivial, but if you edit the workflow file locally and forget to git push, the server-side configuration remains unchanged. The runner only knows what is in the remote repository.

FAQ

Q: Can I trigger on multiple branches? Yes. You can add more branches to the list, like - develop or - staging, to trigger the pipeline whenever code hits those environments.

Q: Does 'on: push' work for tags? You can use tags: instead of branches: to trigger workflows when you create a new release tag, which is a common pattern for CD (Continuous Delivery).

Q: Will this slow down my development? If your test suite takes a long time, consider using Advanced Internal Linking logic to keep your project organized, but keep your test suite fast. A slow CI is a CI that people stop trusting.

Recap

We’ve successfully transformed your manual pipeline into an event-driven system. By configuring on: push, we’ve ensured that every line of code committed to your main branch is automatically validated. This is the heartbeat of Continuous Integration.

Up next: Pull Request Integration — we'll learn how to protect your branch by running tests on Pull Requests before the code is even merged.