Github Actions Overview

I. What is CI/CD

CI/CD stands for Continuous Integration and Continuous Delivery.

It allows us to automate the testing to make sure our code meet certain criterias. After all tests are passed, we can enable actions to automate the delivery of our app.

Let say, if we have a simple Nextjs app and the app is hosted using AWS, what we normally do is building nextjs app, then upload static output that on S3. We can totally make this run automatically and save lots of time, especially for more complicated process.

II. What is Github Actions

There are many events that can happen in a Github repo like branching, merging, creating pr, pushing, etc. Any event can trigger a github action.

Actions are reusable chunks of code for your own workflows.

By running these actions, we can make sure that when everyone push a commit, add label or create a pull request, etc., there’re certain points checked to assure everything is aligned and prevent potential issues.

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

Source: https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions#overview

III. How to implement

In order to implement github actions, you need a workflow file which defines what github event triggers it, the server that run your workflow, what jobs it’s going to do in the workflow, how many steps it has to go through to get the job done.

• Workflow: a configurable automated process that will run one or more jobs. Written in YAML file and are defined in the .github/workflows root directory of your project.
• Event: a specific activity in a repository that triggers a workflow run. (ex: pull request, push,…)
• Job: a set of steps in a workflow that execute on the same runner. Each step is either a shell script that will be executed, or an action that will be run.
• Runner: a server that runs your workflows when they’re triggered. Each runner can run a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows; each workflow run executes in a fresh, newly-provisioned virtual machine.

Here, i have a simple app, and i just want to run the lint check every time someone make a pull request to the master branch.

So create these directory from your application root directory .github/workflows, add a .yml file in workflows folder, and name it anything you like as long as that make sense to you. If you have more workflows, create more yaml files.

// in the yaml file, give the workflow a name
name: Test Continuous Integration

// and on what event this workflow being triggered
on:
  pull_request:
    branches: [ master ]

// each workflow should have 1 or more job
jobs:
  // name of the job
  test_pull_request:
    // which machine to run on. Available options are Ubuntu Linux, Windows, or macOS operating systems.
    runs-on: ubuntu-latest
    // then set a set of steps (instructions) that help build and test our code
    steps:
        // you can add name for each step to be more specific, but it's not compulsory. Always start with a checkout, which will bring your source code into current working directory in the runner
      - uses: actions/checkout@v2
        // setup node if you need to
      - uses: actions/setup-node@v1
        with:
          node-version: 12
        // then run the command as you do on your local machine
      - run: yarn config set ignore-engines true
      - run: yarn install --frozen-lockfile
      - run: yarn lint
      - run: yarn build

That’s it and we can see github actions run when creating a pull request to master branch. As soon as we do this, we can go to Actions tab and see all the running checks.

If there’s a failed check, we can read the error message and fix it.

When all checks are passed, we can see the green mark as below

Notes:

• If you have a more complex app, such as haivng end-to-end testing with cypress, or deploy on aws, or build docker, … There’ll likely be an existing set of actions that you can use or refer. And you can search for those actions here
• When you implement continuous deploy, your 3rd party host might ask for authentication. You can share a secret token from the host with your github repo. Go to Settings tab -> Secrets and Variables -> Actions. Then, you can use it in your yaml file like this

${{secrets.NAME_OF_THE_TOKEN_YOU_CREATED}}

IV. Conclusion

Github Actions has been around for few years and adopted widely because it’s easy to implement and is a great help for development.
I hope this overview give you a general understanding of it. And, you can always look for more details, more use cases in github document.
https://docs.github.com/en/actions