Anatomy of a GitHub Action

Anatomy of a GitHub Action

When I haven’t done something a long time I tend to need a quick overview to remind my brain that I know this stuff, this is exactly that for GitHub Actions.

Workflow’s are triggered when an event occurs in a repository. A workflow contains one or more jobs, each job runs inside its own runner (think vm/container/isolated process). Each job has one more more steps that can either run a shell script or an action.


  • workflow’s: the whole, overall thing, workflow .yaml file.
  • event: PR being opened, issue creation, PR merged, these trigger a workflow to run.
  • jobs: a set of steps in a workflow that are executed on the same runner. Each step is either a shell script or an action.
  • runner: the thing the workflow is running on.
  • action: reusable extension that can simplify a workflow, these typically do complicated frequently repeated tasks. Can get them from GitHub marketplace or write your own.

Parts in a Dummy Workflow #

name: learn-github-actions # name of the workflow
run-name: ${{ github.actor }} is learning GitHub Actions # name that appears in the actions tab
on: [push]  # event's that trigger this workflow
jobs: # list of jobs that will run (in parallel!) 
  check-bats-version: # name of a singular job
    runs-on: ubuntu-latest  # runner that's being used
    steps:  # steps of 'check-bats-version' job
      - uses: actions/checkout@v3 # action to get repo's code
      - uses: actions/setup-node@v3 # action to install node
        with:                       
          node-version: '14'        
      - run: npm install -g bats  # run 'npm install -g bats' using the runner's shell
      - run: bats -v              # run 'bats -v' using the runner's shell

PS: #

  • github.com/nektos/act is a great project I started using recently to test actions locally. Instead of spam pushing commits deploy 1, test deploy, fixed deployment?, having the action run, reading the error log and then updating the workflow you can run and debug everything locally.

  • it’s a good idea from a security perspective to pin versions of actions (especially unofficial actions) to the commit SHA to prevent supply chain attacks

    • uses: actions/checkout@dc323e67f16fb5f7663d20ff7941f27f5809e9b6