What are Github Actions? - Part 3

Alright. We’re back! This week we’ll really start to break down this sample Github Action workflow’s moving parts, but first let’s do a quick recap from last week. In that post we covered ways we could actually start a workflow as well as local environment variables that we could make available for the rest of the workflow to use.

This week we’ll take a look at the first job in our workflow.

jobs:
  changes:
    name: Code & dependency changes
    runs-on: ubuntu-latest
    outputs:
      prefect_flows: ${{ steps.filter.outputs.flows_files }}
      prefect_flows_changed: ${{ steps.filter.outputs.flows }}
      code_dependencies_changed: ${{ steps.filter.outputs.docker_code }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Generate Markdown Summary
        run: echo "Starting CI/CD for flows and dependencies added/modified with commit $GITHUB_SHA" >> $GITHUB_STEP_SUMMARY

      - uses: dorny/paths-filter@v2
        id: filter
        with:
          list-files: json
          filters: |
            flows:
              - added|modified: "${{ env.WORKINGDIR }}/flows/**/*"
              - added|modified: "${{ env.WORKINGDIR }}/blocks.py"
              - added|modified: "${{ env.WORKINGDIR }}/deployments.py"
            docker_code:
              - added|modified: "${{ env.WORKINGDIR }}/flows/**/*"
              - added|modified: "${{ env.WORKINGDIR }}/requirements.txt"
              - added|modified: "${{ env.WORKINGDIR }}/Dockerfile"
              - added|modified: "ints/Dockerfile.agent"

      - name: Generate Markdown Summary
        run: |
          echo Flows: ${{ steps.filter.outputs.flows_files }} >> $GITHUB_STEP_SUMMARY
          echo Code dependency changes: ${{ steps.filter.outputs.code_files }} >> $GITHUB_STEP_SUMMARY

There is a lot to unpack here, especially if you are completely new to Github Actions. It would definitely be advised to have a little bit of familiarity with YAML in general, and to follow along with GitHub’s Workflow documentation. Workflow’s are comprised of one or more jobs. In this example we see a single job. It’s job_id is changes. This job_id is just any unique value you want to give the job. Nested inside of our jobs.<job_id> of changes we have a map of some configuration data for this job. Let’s go through the 4 YAML keys one by one.

name

Well, this one is kinda self explanatory. name serves as means of displaying the job’s name in the Github UI. I often use this to display a job name that is more descriptive than the previously discussed job_id YAML key. Here I have given a little more context by giving my jobs.changes.name a value of “Code & dependency changes”. Hopefully that gave a little more of glimpse into what this job is supposed to be handling.

runs-on

runs-on can definitely be it’s own post, but for the sake of brevity I’ll only be glossing over this. In workflows each job runs in a runner environment. The Github documentation succinctly sums it up with the following:

Runners are the machines that execute jobs in a GitHub Actions workflow. For example, a runner can clone your repository locally, install testing software, and then run commands that evaluate your code.

Personally, I have never ran into any issues with using ubuntu-latest for my runs-on value. This, of course, will all depend on what your goals with these jobs are.

outputs

This key is especially useful if you want to be able to pass information from one job to downstream dependent jobs. Although you can’t see it yet, in my example workflow this job’s output is one of the main factors in determining if any downstream jobs even need to be ran. More on that next time.

steps

Here we go. In steps we begin to outline our……well…..step-by-step instructions for our deployment. As I previously mentioned in my first post on Github Actions, we can easily leverage already built workflow steps by looking through the Github Marketplace. Of the 4 steps in the example YAML above, I have done just that with 2.

• uses: actions/checkout@v3
• uses: dorny/paths-filter@v2

These two steps I snagged from the Github Actions Marketplace. With checkout we can have our runner checkout the repository that has triggered the workflow, and with paths-filter I am able to define logic to allow for conditional execution of workflow steps based on the files modified.

The remaining steps are just job summaries that Github’s UI outputs so that someone viewing the workflow doesn’t need to go into the logs to see important information about the run. You can echo any text you deem useful into the $GITHUB_STEP_SUMMARY environment variable and it will be “prettified” for you!

In my particular workflow, I have just opted to output some very basic information (e.g. a list of files that were added or modified).

Extra Resources:

• More about the $GITHUB_STEP_SUMMARY