At the start of my team’s recent software development project, we set up a CI-CD pipeline that would run every time we pushed to our repo. The pipeline would run our tests and validate our database migrations. This worked until we integrated with Cypress Cloud. After the integration, each run of our pipeline got more expensive. To keep the cost manageable, we needed better control over when our pipelines ran. The answer was GitHub’s action triggers.
Focusing Each Action Workflow File
To control when parts of the pipeline ran, we needed to split them up into multiple workflow files. Each .yaml file in .github/workflows becomes a pipeline and each pipeline can have its own trigger conditions. GitHub Action Triggers are events that GitHub provides when different changes happen in a repo. Each action workflow will listen for any triggers in its ‘on’ section. To correctly launch our actions we used the following triggers. We split our pipeline into separate deploy, Cypress test, and unit test workflows, which I will reference to explain why we chose certain combinations of GitHub action triggers.
Push Trigger
Push tells GitHub to launch this workflow whenever a commit matching the filters is provided to the trigger. The settings we used were the branches and tags settings that filtered for commits pushed to our dev branch and any commits tagged as a deploy. We wanted the deploy pipeline to run whenever a commit with “-deploy” somewhere in the tag was pushed to the repo. The second example only runs when a commit gets pushed to our dev branch. That trigger is an extra condition on the Cypress branch that ensures the tests passed after new code has been merged.
push:
- "*-deploy*"
push:
branches:
- "dev"
Workflow Dispatch Trigger
This trigger allows the manual execution of a workflow. If there are any required inputs or arguments then GitHub will prompt you for those when clicking in the UI. See the screenshots below. That menu is found in the actions tab of the repo and then click on the specific workflow that you would like to launch.
workflow_dispatch:
Pull Request Trigger
In this case, we want to restrict the workflow to running only when a pull request is modified. Github emits events related to pull requests that we can subscribe to. For the Cypress test pipeline, we wanted to run the tests for a new PR and anytime new commits were pushed to a PR. The pull request trigger takes an array of event types. The first type we used was the opened event which will run the pipeline whenever a new pull request is opened. Any time a new commit is pushed to an existing pull request then GitHub fires a synchronize event. For more details on the pull_request event take a look at this article.
pull_request:
types: [opened, synchronize]
Example Triggers
The following are the definitions for the workflows I mentioned at the start. They mix and match the triggers mentioned in this post to run each pipeline for the correct events.
name: Cypress Testing
on:
workflow_dispatch:
pull_request:
types: [opened, synchronize]
push:
branches:
- "dev"
name: 🧪 Lint and Vitest
on:
workflow_dispatch:
push:
name: 🚀 Deploy
on:
workflow_dispatch:
push:
tags:
- "*-deploy*"
We used those events to control our testing pipeline and reduce our Cypress cloud costs. There is an entire list of supported triggers in GitHub’s documentation. The list of events GitHub provides to control when actions workflows launch is extensive. It’s a good place to start if you’re looking to reduce when different parts of a CI pipeline runs and save money on action costs or automate tasks in a repo.