Automate your workflows using github actions

CI/CD has become an essential part of any successful software project. In this blog post, I will share my experience with Github actions, a new tool to quickly build, test and deploy your code right from any of your Github repositories.

Actions terminologies

Workflows

A workflow is a descriptor used to define your whole CI/CD pipeline with a combination of one or more jobs, steps and they are either scheduled or triggered by several events. If you are comfortable with basic YAML syntax, then you can quickly start writing an action workflow. A workflow yaml can be placed inside .github/workflows directory of your repository.

Jobs

A job is a set of steps that execute on some runner. By default, if you have multiple jobs defined on your workflow, they will run in parallel. You can change this behavior and make them run sequentially by making one job dependant on the other.

jobs:
  job1: ...
    ...
  job2:
    needs: [job1]

Steps

Each job can be composed of one or more steps. A step is an individual task that can run commands in a job. It can be either an action or a shell command. An action is a standalone command that can perform several tasks ranging from checking out code, setup a development environment, etc. You can find a massive list of readymade actions from GitHub marketplace

- name: Checkout repo
  uses: actions/checkout@v2

- name: Set up JDK 11
  uses: actions/setup-java@v1
    with:
      java-version: 11

- name: Run tests
  run: sbt test

Events

An event is a specific activity that action can use to trigger your workflow. You can find a list of events here

Runner

A runner is a server that runs each job defined in your workflow. You can either use the one hosted by Github or host your own. Github currently supports Ubuntu Linux, Microsoft Windows, and macOS See more about available environments

Types of Actions

There are different types of actions available.

1. Docker container based:

It packages the environment with code to execute a specific task.

2. Javascript actions:

They are built using javascript (node). It runs directly on a runner machine.

3. Composite run steps action:

It allows you to combine multiple run steps of a workflow.

Matrix builds

Matrix build lets you quickly run your workflow against multiple runner environments and versions.

jobs:
  test:
    name: Test on node ${{ matrix.node_version }} and ${{ matrix.os }}
    runs-on: ${{matrix.os}}
    strategy:
      matrix:
        node_version: [8, 10, 12]
        os: [ubuntu-latest, windows-latest, macos-latest]

    steps:
      - uses: actions/checkout@v2

      - name: Use Node.js ${{matrix.node_version}}
        uses: actions/setup-node@v1
        with:
          version: ${{matrix.node_version}}

      - name: npm install, build and test
        run: |
          npm install
          npm run build
          npm test

The above workflow file will setup multiple nodeJs versions on all the defined operating systems and run the commands described in each step.

Can we run actions locally?

If you want fast feedback while writing your workflow and test each step without pushing your changes to GitHub, then there is a handy tool available to mimic the action runner locally. Read more in the act repo

Creating your own actions

You can create your actions and publish them in the Github marketplace. It will allow others to use your action, or even you can use it on multiple projects. The typical syntax used to reference an action in a step is action-name@version. You can also use <username>/<repo-name>@<branch-name> if one such action is not yet published to the marketplace.

I will write more detailed steps on building your own action using docker or javascript in an upcoming post.

See an example workflow I’ve written for the Lunatech scala3 course repo here

Bonus: Here is the source code a github action I’ve developed release-downloader Repo

I have given a talk at Lunatech about my experience using Github actions. You can find the video below