Getting Started With GitHub Actions

The CI/CD tool built and used by GitHub—Actions—allows you to build, test and deploy your code straight from GitHub, taking care of all the automation to make it happen smoothly. The possibilities are endless!

How much of your workflow can you automate as a developer today? With the inception of CI/CD with tools like Jenkins, Circle CI, Travis and others, you can automate a lot of your workflow easily.

If you are reading this, you probably use GitHub to host and Git to manage versions of your projects. What if I told you that you can do those automations right inside GitHub and for free?

What Is GitHub Actions?

GitHub Actions is the continuous integration and continuous delivery tool built and used by GitHub. It allows you to build, test and deploy your code straight from GitHub, taking care of all the automation that enables this to happen smoothly without any third-party CI/CD tools. The possibilities you can build and automate using this are endless, and with the ease of working directly from where your code is stored—GitHub cannot be matched.

Why Is It Important?

This might be the next thing you are wondering: Why is GitHub Actions important? GitHub Actions has a lot of instant benefits to you, the developer. The first thing is the flexibility of building out automation workflows right from GitHub. That is super important—that a value-added service is layered on top of a service you use and are used to. You set up Actions in the same place you set up PRs—how cool is that?

The next thing that will excite you is that GitHub Actions is free, forever for any public project you have on GitHub. I think that is super amazing, especially for people who would like to get into DevOps—it’s a great way to do so. It also has Docker support and you can run Actions in different virtual machines inside of the GitHub infrastructure.

The last thing I think is super valuable is the presence of so many automation templates. There is even a whole marketplace for that, where you can create a custom automation and share for your community.

What Is It Made Up Of?

GitHub Actions setup usually looks something like this:

name: GitHub Actions Demo
on: [push]
jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
      - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
      - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
      - name: Check out repository code
        uses: actions/checkout@v2
      - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
      - run: echo "🖥️ The workflow is now ready to test your code on the runner."
      - name: List files in the repository
        run: |
          ls ${{ github.workspace }}
      - run: echo "🍏 This job's status is ${{ job.status }}."

Let us break down every part of this so you can get a clearer picture.

YAML

The first thing you see is a YAML file. All GitHub Actions are defined in a YAML file and in a specific workflow folder that we will see later in this post. Inside the file, the first thing you see is the name of the workflow.

Event

Events are activities that occur while you are working on a project hosted on GitHub, things like pushing to a repo or creating a pull request. In the syntax above, you can see that the event is “on: [push]”—that means that, for this particular workflow, the action is triggered once a push is made to the repository and the job that you have set up will run.

Jobs

A job literally answers the question, “What do you want me to do?” It contains every other thing in the workflow file including runners, steps and actions. In this block, you define everything and set up all the logic for the desired workflow.

Runners

Runners basically let you specify the virtual machine live in the GitHub infrastructure you want this automation to run on. By default you get Ubuntu—however, you can choose macOS, Linux or Windows, or even select your own custom VM. The syntax we have above runs on the latest Ubuntu VM, denoted by the “runs-on” option.

Steps & Actions

The steps section is where you define the action you want; you can have more than one action. It usually has a name, runs and uses options. First you choose a name for the action, then you can (optionally) choose a run command or use a GitHub in-built action command.

What We Are Building

Let us build our first simple GitHub Action that will be a linter that checks our code for linting errors once we push the code to GitHub.

Setting Up Actions

The first thing to do is to create a new repository on GitHub. I called mine LinterAction, but feel free to call yours something unique.

Initialize the ReadMe file too. Now, to create an Action workflow, you have to create a new file in the .github/workflows directory. This is very important part and, if not done accurately, Actions will not work.

Inside that folder create a blank.yml file or click on Actions and choose the blank template.

Inside the blank.yml file, copy the code block below into it:

name: My Linter Action
# Controls when the action will run. 
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
# Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2
# Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world!
# Runs a set of commands using the runners shell
      - name: Run the linting service
        uses: github/super-linter@v3Testing it all out

The spaces and indentation are very important, so take note of them. After copying, save the file and you will see that it runs automatically and checks linting rules. For this first version, it sees no errors because we have a readme file only.

For further testing, let us add a new file that will have linting errors to the project, like an HTML file with one element that does not have closing tags. Create a new file in the same repository and call it index.html.

Copy the code block below inside it:

<html>  
<div>    
<p> Hi my name is Lotanna <p>  
</div>
</html>

You can see the closing P tag is not closed right. If you save the file, the Action will run the linter which will reveal the issue.

After you fix the paragraph tag and add a doctype, all linting checks will pass, and you’ll see that, for every commit or every PR on that project, the linting Action will automatically take place. This will help whoever has to merge it to immediately fix the problem without looking at the codebase.

Conclusion

You have been introduced to GitHub Actions and how it can be used to simplify your workflow through automation. You have also seen how important it is, so consider trying it out today and tell me about your first GitHub Actions experience!