Git-Based CI Triggers: Automating on Events
Think of Git events like push or pull_request as the "play" button for your automation. This is how CI systems automatically run tests on new code. The footgun is using broad triggers, like push on all branches, which causes costly and redundant runs.
Why it exists
To eliminate manual script execution and ensure that code changes are consistently and automatically tested, built, and deployed. It connects the version control system directly to the quality and deployment pipeline, making integration truly "continuous."
The mental model
Think of your Git repository as a switchboard and your CI/CD pipelines as the devices plugged into it. A Git-based trigger is the event that flips a specific switch. A push event flips the "run unit tests" switch. A pull_request event flips the "run integration tests and static analysis" switch. A merge to the main branch flips the "deploy to production" switch. You define which events flip which switches.
How it works
In your CI configuration file (like .github/workflows/main.yml), you define an on: block. This block specifies the event that will trigger the workflow. Common events include push, pull_request, workflow_dispatch (manual trigger), and schedule (cron job). You can add filters to make triggers more specific, such as running a workflow only for pushes to the main branch or for changes in a specific directory (paths). When Git detects a matching event, the CI platform queues and runs the associated job.
When to use it
Use triggers for any repetitive task that should happen in response to code changes. Three key places are: first, running tests and linters on every push to a feature branch; second, running more extensive integration or end-to-end tests when a pull request is opened; third, automating deployments when code is merged into a release or main branch.
When not to use it
Don't use automated triggers for actions that require careful, manual sign-off and can't be fully tested, like decommissioning a production database. Also, avoid triggers for workflows that are extremely long or expensive if they don't need to run on every minor commit; consider using manual triggers (workflow_dispatch) or batching changes instead.
One canonical example
A common GitHub Actions setup is to trigger a workflow when a pull request is opened or updated that targets the main branch. The configuration would look like: on: pull_request: branches: [ main ]. This ensures that every proposed change to the main branch is automatically tested before a human even begins a review, catching errors early.
Interview question
What is the primary reason to use specific filters (e.g., branches, paths) with Git-based CI triggers?
- a.To reduce the number of workflow runs, focusing only on relevant changes or branches.Correct
- b.To define the exact order in which multiple CI jobs within a single workflow should execute.
- c.To enable manual approval steps for critical deployments to production environments.
- d.To ensure every code change, regardless of branch or file, always runs a full CI pipeline.
Why? this is the answer
Specific filters prevent the "footgun" of broad triggers, which lead to costly and redundant workflow runs. They ensure workflows execute only for relevant changes, unlike option D which describes the inefficient use of broad triggers.
Just read this? Test yourself on what you have been reading.
Read the original → docs.github.com
- #ci/cd
- #git
- #github actions
- #automation
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles