Introduction to GitHub Actions

July 9, 2020

GitHub Actions enables you to create custom and automated software development workflows (including CI/CD) directly in your GitHub repository.

Suppose we have a GitHub repository, there are different kinds of events that can happen to that repo like starring, pull-request or create an issue; these events can be used to trigger an automated workflow. GitHub can spin up one or more containers for us in the cloud and execute given instructions to do something useful.

GitHub will log the progress of each step and make it very clear if something failed. The good thing about GitHub Actions is that instead of writing these steps on our own, we can use the ones implemented by the community.

You can write individual tasks called actions, and combine them to create a workflow. Workflows are automated processes that you can set up in your repository to build, test, package, release, and deploy any project on GitHub. You can create actions by creating custom code that interacts with your repository in any way you would like. For example, an action can publish npm modules, send updates to Slack, or deploy production-ready code.

We can use GitHub Actions to perform real-world tasks such as CI/CD, publish to NPM, deploy to Azure/AWS, and so on.

Getting Started with GitHub Actions

  1. Go to any repository, where you want to create a workflow, and navigate to the Actions tab.

repo img

  1. Select a workflow from the ones available, or create a new one.

actions img

  1. To create your own workflow create a .yml file in the path .github/workflows/action1.yml. Commit the file, GitHub will automatically understand that it is a workflow.

ga img

  1. You can monitor you workflow logs in the same Actions tab after you have set it up.

log img

How to create custom actions for common uses

Continuous Integration

The whole idea behind continuous integration (CI) is to have developers submit their code to the main codebase in small maintainable chunks, usually on a daily basis. Those changes should be automatically tested against the main codebase.

You can use your own project, but I am using a simple node project.

Create a new file in .github/workflows/action.yml.

name: Node Continuous Integration

        branches: [ master ]
        runs-on: ubuntu-latest
            - uses: actions/checkout@v2
            - uses: actions/setup-node@v1
                node-version: 12
            - run: npm ci
            - run: npm test
            - run: npm run build

The above action does the following:

  1. We set up an action with name Node Continuous Integration.
  2. This action is triggered when there is a pull request on the master branch. The event which triggers the action is mentioned under on:.
  3. An action has one or more jobs. The first does the following:
  • Spins up an ubuntu virtual machine.
  • actions/checkout@v2 Brings the source code to the current working directory. checkout@v2 is an existing action from GitHub.
  • Installs node.
  • Installs app dependencies, using npm ci.
  • Runs the command npm test followed by npm run build, we can use our preferred libraries like jest and webpack; it executes the test script mentioned in package.json.

If there are any errors or build failures, then it shows up in the log in the actions tab of our repository by a green check or a red ‘x’.

greencheck img

Continuous Deployment

Once you have a valid pull request and when we merge that code into the master branch, we also want to deploy the app to production. Continuous deployment is about pushing that code out to production.

If your website is hosted on GitHub, then you can use the github-pages action. However, if a third-party provider hosts your app, then they provide options like SFTP, FTP, and SSH. This is fine when we are doing it manually, but not so easy when we are using a CD tool. We will have to share a secret token with GitHub for the CD process.

Let’s see how to deploy to firebase:

    firebase init
    firebase deploy --only-hosting

    firebase login:ci

This provides a secret token which we can share with GitHub Go to the settings tab on the GitHub repository. Create a new FIREBASE_TOKEN secret.

secret img

name: Firebase CD

        branches: [ master ]

        runs-on: ubuntu-latest
            - uses: actions/checkout@master
            - uses: action/setup-node@master
              node-version: 12
            - run: npm ci
            - run: npm run build
            - uses: w9jds/firebase-action@master
                args: deploy --only-hosting
                  FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}        

The above action deploys our app to firebase whenever we push changes to the master branch. Above w9jds/firebase-action@master is a third-party action published on GitHub.


There are several CI tools you can use such as Jenkins, Travis CI and Circle Ci. The main difference between Jenkins and GitHub actions is that Jenkins is a self-hosted automation server whereas GitHub actions is a software as a service (SaaS). GitHub Actions is free for open source repositories and has a free limit for private repositories. GitHub Actions integrates CI into the GitHub ecosystem. Using an external CI tool like Travis is useful when you want to move your repository to another Git platform without rewriting the entire CI process.

There are other cool things you can do with GitHub Actions, like publishing to NPM package; we can automatically publish new versions of the code to npm. In GitHub marketplace, we see Actions and Apps. Actions are reusable chunks of code for your own workflows, whereas Apps are fully-managed integrations that don’t require any code. The nice thing about apps is that they can be installed with a few clicks, and they can be used across multiple repositories. So, when you are automating with GitHub Actions, it’s a good idea to ask yourself if you want a fully built app or to build your own workflow. Check out the actions or apps offered in GitHub Marketplace.

References and Resources