Introduction
Pipelines as code have become the de-facto way to build and deploy software in recent years, which greatly improves code quality and build repeatability. Most CI/CD platforms, however, only implement SCM pushes as the triggering event for their workflows. For enterprise-scale software development this often results in large, monolithic pipelines with complex conditional logic and un-intuitive workflows, as a large number of steps must be combined in a single workflow.
GitHub Action Workflows: Basics
GitHub Actions — Github’s CI/CD offering — has taken a slightly different approach. GitHub workflows can be triggered from a wide variety of events within the GitHub ecosystem, which allows for much smaller, focused workflows.
Rather than having a single file that defines the whole software development process, GitHub supports having multiple workflow files, each with their own triggers, which can execute different parts of the software development pipeline. One workflow may build and test newly opened PRs, while another deploys artifacts when new releases are created, and yet another workflow can then execute post-release tasks. The ability to break down and separate your pipeline logic lets developers quickly engage with the tasks they need to automate and avoid getting lost in complex pipeline steps and conditions.
In addition to the normal software development process, GitHub workflows can be used to automate other tasks around the development process such as updating documentation or building reports.
Expanding Your Arsenal: How to Leverage GHA Triggers
Here are some examples of how you can build small, single-focus workflows to improve your software delivery flow:
Development Tasks
Use the status trigger to create or reduce noise:
Workflows can trigger based on the status of a commit, which indicates whether external checks have passed for a specific commit. These could be used to notify developers about a deployment failure, or could be used to trigger downstream workflows only when a previous check from an external system has finished successfully.
Use the release trigger to publish artifacts and update tags
Rather than building and pushing artifacts upon each commit to your main branch, you can use the release trigger to publish artifacts once a full release has been cut. This could be used to publish artifacts, to notify stakeholders, to update documentation, or to update dependent projects (if you're not already using dependabot).
Use the registry_package trigger to automatically scan new packages
Use the pull_request trigger to spin up integration testing environments
The more that can be validated before merging into your main branch, the better. The pull_requesttrigger can be used to run integration tests that must pass before a pull request can be merged into your main branch.
Similarly, the create trigger could be used to create testing environments for your feature branches at the time of branch creation, rather than just at PR time, if that works better for your development workflow.
Use a create trigger to set up a new repo from a template
GitHub's template repos are a great way to get developers started quickly on commonly used technologies. Often these repos need some configuration and setup after initialization, such as setting up environments, or configuring the repo's name throughout the project. GitHub actions can be used to automate much of this by automatically running a workflow upon creation of the main branch.
Here's an example of initializing a lab repo.
Expanding the Use Case to Other Tasks
Use the gollum (wiki) trigger to lint wiki pages.
If you're using GitHub's wiki feature, the gollum trigger can be used to automatically run spelling, grammar, or tone linting against updated wiki pages to help keep all of your documentation consistent.
Ticket-based automation
The project, project_card, project_column, issues, and issue_comment triggers can be used to automate any tasks around your ticket-based workflows.
Use the schedule trigger to check for abandoned feature branches
The schedule trigger can be used to run scans against a repo on a regular basis, such as checking for branches that haven't been updated in a certain number of days. The workflow can then prompt developers via an Issue or a slack integration to review and clean up the old branches.
Generating reports and general utility scripts with the workflow_dispatch trigger
GitHub workflows can be used for anything that can be automated, not just code build tasks! Most organizations have collections of miscellaneous scripts that are used for varying tasks such as gathering metrics, or generating reports. These can be built into GitHub workflow files, and then the workflows can be triggered manually (via workflow_dispatch), on a schedule (via schedule), or chatops-style (via issues and issue_comment). The outputs from these workflows can be collected via artifacts, workflow summary outputs, or issue comments.
Conclusion
While GitHub does technically support monolithic "all-in-one" pipelines that handle all of your build and deploy tasks in one workflow, the variety of workflow triggers means that you can build much simpler workflows that are easier to understand and maintain, and have a lower barrier to entry.
The ability to trigger arbitrary automation from a central location also means that your workflows can be used for much more than just building and deploying code, and can help reduce manual setup for such tasks.
The above list isn't exhaustive by any means, but hopefully it can be a source of inspiration for how GitHub workflows can be used to improve flow and reduce manual toil in your organization.
