I come across a lot of “greedy” GitHub Actions, where automation is running across a whole project instead of only on the parts that are relevant. Examples might be code linters that report problems with documentation folders, or the inverse of that. It’s especially problematic in monorepos where we probably want to use the same tool when we’re doing the same task for different subfolders, but that tool might not make sense to run everywhere.

For GitHub Actions (other platforms have equivalents), there are paths and paths-ignore parameters you can add to the pull-request and push configuration. For example, here’s the first few lines of a GitHub action that only fires on a push event to one of a specific set of paths:

name: check-links

on:
push:
paths:
- 'project/docs/**'
- 'another-project/docs/**'

In terms of functionality, there’s no harm in using the common pattern of having a job that runs, checks if any of the changes need it to do anything, and exiting if not.

In terms of both usability and performance, however, I greatly prefer this approach of filtering with paths. If a change doesn’t match a path, the job doesn’t need to wait for resources to run and then realise it doesn’t need to run. And the humans don’t need to scroll past 10 inapplicable jobs that woke up, did nothing, and exited to find the one that related to the project they’re actually working on.

Take some time to check the automation on the repositories you work on and if there are exemption checks within the jobs, adjust them so that they don’t run at all if the changes don’t require it – I can’t share the performance improvements I gained on a recent project, but I would love to hear your anecdotes in the comments if you have them :)