What are Github Actions? - Part 2
Last time I shared an entire Github Actions workflow script. In this post I’ll take a little bit of a deeper dive into only a few of sections of the YAML syntax for workflows. Let’s take a look at today’s relevant sections again.
name: Sample GH Action Workflow
on:
workflow_dispatch:
inputs:
SUB_DIR:
required: true
type: string
ENVIRONMENT:
required: true
type: string
PROJECT:
required: true
type: string
REGION:
required: true
type: string
ZONE:
required: true
type: string
GCP_AR_REPO:
required: true
type: string
env:
SUB_DIR: ${{ inputs.SUB_DIR }}
WORKINGDIR: ints/${{ inputs.SUB_DIR }}
WORK_QUEUE: ${{ inputs.ENVIRONMENT }}
ENVIRONMENT: ${{ inputs.ENVIRONMENT }}
PROJECT: ${{ inputs.PROJECT }}
REGION: ${{ inputs.REGION }}
ZONE: ${{ inputs.ZONE }}
GCP_AR_REPO: ${{ inputs.GCP_AR_REPO }}
GCE_INSTANCE: prefect-docker-${{ inputs.ENVIRONMENT }}-vm
GCE_INSTANCE_ZONE: ${{ inputs.REGION }}-${{ inputs.ZONE }}
name
The first of our yaml keywords here is name. name, unsurprisingly names the github actions workflow. You can toss any thing you want here, and you’ll be able
to identify the workflow by this name value in Github’s Action tab.
on
This is where things start to get a little more interesting. on allows us to configure what types of actions can potentially “trigger” our workflows. There are variety
of available events that trigger workflows. For this introduction I have chosen one
we can have complete control over. workflow_dispatch ensures that a workflow will only trigger once we have manually taken the steps to kick if off ourselves. In Github
we can see visually see if a particular workflow has a workflow_dispatch event trigger by selecting a workflow and seeing if Github explicitly confirms this configuration (see
the screen shot below for an example).
In our example I utilized inputs. With inputs you can optionally specify inputs that are passed to the workflow. This option can allow you to write more general workflows
that can easily be re-used depending on what inputs you choose to pass in. I tend to use this option a lot. Albeit not all of the inputs change often. For instance, I don’t often
deploy to different cloud regions or zones, but I will almost always pass in the value dev for ENVIRONMENT to have my workflow string format dev as a suffix or prefix in the names of any infrastructure my CI/CD workflow
creates. Once things are looking the way I want I’ll update that ENVIRONMENT input value to prod prior to having the workflow run one last time. Your mileage may vary, but I find inputs
to be a powerful option.
env
Our last workflow section for today is env. This kind of goes hand-in-hand with inputs. Here we are able to hardcode any environment variables we want to have available for our use
further downstream in the workflow. My general use pattern tends to be to surface any inputs here, and possibly concatenate them with any other required strings that my workflow needs.
There are some limitations to note here! Variables in the env map cannot be defined in terms of other variables in the map. We’ll discuss how you access these environment variables in the my upcoming
posts, but for the time being we can think about using these workflow env vars similar to how we could use shell env vars. For example, if we launched this workflow with an input value of dir1 for SUB_DIR,
cd $WORKINGDIR would interpolate to cd ints/dir1.