Github Actions Short-Circuit for faster turnarounds

Posted: 19 September, 2021 Category: recipes Tagged: github-actionsci-cd-workflows

Bootstrapping a ci/cd pipeline is fraught with missteps and re-tries. Sitting there waiting for everything to be fetched, built, tested, deployed etc uses up a lot of time and can slow down development. This is what I've cobbled together to speed things up a bit.

1. Ensure your workflow triggers ignore irrelevant files

This saves a lot of unnecessary CI/CD work, and is done using the paths-ignore rule. Here's a snippet of one of my workflow files which is only interested in linting, running and testing the nodejs app and doesn't care at all about anything to do with deployment or provisioning, so I path-ignore that stuff.

# ...
    types: [opened, synchronize]
    - 'deploy/**'
    - '.github/workflows/tf-*.yml'
# ... etc ...

2. Setup a manual action

Github actions has a feature that will allow you to trigger a workflow whenever you like, using the workflow_dispatch trigger:

name: Quick Test Workflow


# ... etc ...

3. emoji-exclamation ensure the workflow is commited to your main branch at least once

Without this initial commit, github will not list the workflow on the 'Actions' tab of your project, and it needs to be listed before you can trigger it. Once it appears under the actions tab, you can bypass having to always commit to the main branch (see step 5)

4. Copy problematic jobs into your manual action workflow

Now you can begin rapid testing: Make edits, commit locally and push to github. If you've made your workflow triggers sensible, hopefully the push will trigger only one or no workflows at all, saving you time. Now, head over to the actions tab of your repo after you've pushed your branch.

5. Manually trigger the workflow to test pipeline behavior

  • go to the actions tab of your repo
  • select the workflow in the left hand panel
  • click the run workflow button at the right, making sure to first select the branch that you've just pushed. This extra shortcut means you don't have to have merged to main (and sit through all the workflow jobs which that entails). You can just keep updating that branch and retriggering the workflow to test!

Here's an example of my workflow that I just called 'Tf Sanity checks' that I use in this way. example manually-triggered workflow screenshot

That's it! Hope this saves someone some time.