Automate your workflow with GitHub Actions

By Madis Kõosaar
github certification automation actions ci cd

Prepearing for GitHub certification - Automate your workflow with GitHub Actions

Table of Contents

How does GitHub Actions automate development tasks?

GitHub decreases the time from idea to deployment

  • Communication - eg. code reviews in pull requests, GitHub issues, project boards, wikis, notification, etc.
  • Automation - GitHub Actions enables to automate workflows in the software development process (CI/CD).

What is GitHub Actions?

  • GitHub Actions are packages scripts to automate tasks.
  • Can be configured to trigger complex workflows eg. each check in to a specific branch, at timed intervals or manually
  • Scripts that adhere to a yml data format

Using open source GitHub actions

  • Some recommended community standards with open source should include:
    • README
    • code of conduct
    • contributing file
    • issue templates
  • Recommendations before using open source GitHub actions:
    • Review actions action.yml file for inputs, outputs and make sure the code does what it says it does
    • Check if the GH action is in the GitHub Marketplace - not mandatory
    • Check if action is verified in the FH Marketülace - means GitHub has approved the use of this action
    • Includes the version of the action you are using by specifying a Git ref, SHA, or tag

Two types of GitHub actions

  • Container Actions:
    • the environment is part of the actions code
    • Can only be run in Linux environment that GitHub hosts
    • Supports different languages
  • JavaScript Actions:
    • don’t include environment in the code
    • need to specify the environment to execute these actions
    • can run in a VM in the cloud or on-prem
    • support Linux, macOS, and Windows environments.

The anatomy of a GitHub action

  • Samples of actions:
  • Actions that performs a git checkout
steps:

    - uses: actions/checkout@v1

    - name: npm install and build webpack

    run: |

        npm install

        npm run build
  • Container action
name: "Hello Actions"

description: "Greet someone"

author: "octocat@github.com"



inputs:

    MY_NAME:

    description: "Who to greet"

    required: true

    default: "World"



runs:

    using: "docker"

    image: "Dockerfile"



branding:

    icon: "mic"

    color: "purple"

What is a GitHub Actions workflow?

  • A GitHub Actions workflow is a process that you setup in your repository to automate software development life cycle tasks.
  • You can build, test, package, release, or deploy any project on GitHub
  • Workflow consists on actions in a .yml file in the .github/workflows directory in your GH repository
  • Sample:
name: A workflow for my Hello World file

on: push

jobs:

    build:

    name: Hello world action

    runs-on: ubuntu-latest

    steps:

        - uses: actions/checkout@v1

        - uses: ./action-a

        with:

            MY_NAME: "Mona"
  • on: attribute is a trigger that specifies when the workflow will run
  • In the sample it runs when there is a push event
  • Can specify single on: push or an arry of events on: [push, pull_request] or an event configuration map that schedules workflow or restricts the execution of a workflow to specific files, tags, or branch changes
on:

  # Trigger the workflow on push or pull request,

  # but only for the master branch

  push:

    branches:

      - master

  pull_request:

    branches:

      - master

  # Also trigger on page_build, as well as release created events

  page_build:

  release:

    types: # This configuration does not affect the page_build event above

      - created
  • event will trigger on all activities types unless specified otherwise
  • More on events
  • Workflow must have one job - a job is a section of the workflow that will be associated with a runner
  • runner - machine/server where a job will run (GH hosted or self-hosted).
  • runner is specified with runs-on: attribute
  • More info on workflow syntax

GitHub-hosted versus self-hosted runners

  • GitHub-hosted runners or self-hosted runners. If you use a GitHub-hosted runner, each job runs in a fresh instance of a virtual environment that is specified by the GitHub-hosted runner type you define, runs-on: {operating system-version}.
  • Self-hosted runners, you need to apply the self-hosted label, its operating system, and the system architecture runs-on: [self-hosted, linux, ARM32]

GitHub Actions may have usage limits

Identify the components of GitHub Action

Workflow

  • Is an automated process that you add to your repository
  • Needs to have at least one job
  • Can be triggered by different events

Jobs

  • A section of the workflow that will be associated with a runner
  • Can be GH-hosted or self-hosted
  • Can run on a machine or container

Steps

  • Is an individual task that can run commands in a job

Actions

  • Are the standalone commands that are executed
  • Can reference GH actions
  • User your own actions
  • Run commands run: npm install -g bats to be executed on the runner

Configure a GitHub Actions workflow

Configure workflows to run for scheduled events

  • The schedule event allows you to trigger a workflow to run at specific UTC times using POSIX cron syntax
on:

  schedule:

    - cron:  '*/15 * * * *'

Configure workflows to run for manual events

  • Manually trigger a workflow by using the workflow_dispatch event
  • Can choose which branch to run on or set optional inputs that GH will present as form elements
  • This event allows you to run the workflow using the GitHub REST API or by selecting the Run workflow button
on:

  workflow_dispatch:

    inputs:

      logLevel:

        description: 'Log level'     

        required: true

        default: 'warning'

      tags:

        description: 'Test scenario tags'
  • Can use the GitHub API to trigger a webhook event called repository_dispatch.
  • Trigger a workflow for an activity that occurs outside of GitHub
  • This manual event requires you to do two things:
    • send a POST request to the GitHub endpoint /repos/{owner}/{repo}/dispatches with the webhook event names in the request body
    • configure your workflow to use the repository_dispatch event

Configure workflows to run for webhook events

  • Run workflow when specific webhook event occur on GitHub
  • Webhook events

Use conditional keywords

  • Can use conditional if keyword
  • Evaluation expression needs specific syntax {% highlight yml %} ${{ }} {% endhighlight %}
name: CI

on: push

jobs:

  prod-check:

    if: github.ref == 'refs/heads/main'

    runs-on: ubuntu-latest

    steps:

      ...
  • Note: some expressions GitHub automatically evaluates that’s why
$

is missing.

Disable and delete workflows

  • It’s possible to disable a workflow temporarily
  • It’s possible to cancel a workflow
  • You can delete the workflow if wanted

Use an organization’s templated workflow

  • Can define a workflow template in the organizations .github repository

Use a specific version of an action

  • It is recommended to refer a specific version of action
steps:    

  # Reference a specific commit

  - uses: actions/setup-node@c46424eee26de4078d34105d3de3cc4992202b1e

  # Reference the major version of a release

  - uses: actions/setup-node@v1

  # Reference a minor version of a release

  - uses: actions/setup-node@v1.2

  # Reference a branch

  - uses: actions/setup-node@main

Exercise