Get Started with GitHub Actions

Hi, my fellow developers,

Pipelines to perform automation tasks have become a standard in an application lifecycle and have even become a requirement with DevOps adoption.

You probably have already heard about Continuous Integration and Deployment and you are using GitHub as a repository provider.

Did you know GitHub can also meet your automation needs, with GitHub Actions providing a full out-of-the-box feature?

In this blog post, we cover the GitHub Actions introduction and dive into the details of a Workflow definition.

Enjoy!

Why you need a CI/CD

First, let’s define CI/CD and explain why we have to differentiate these concepts.

Continuous Integration

CI refers to “Continuous Integration,” an automation process for development teams. The aim of a CI is to smoothly integrate changes made by different developers and ensure team requirements are reached. CI can run unit tests but also addresses code coverage, bug finding, or technical rules decided by teams (e.g. avoid repeated code blocks). This helps a lot when working with several different branches, maintaining the quality level and improving trust in the code.

Continuous Delivery/Deployment

Continuous Delivery is the ability to automate code releases by adding gates in the pipelines that ensure the product is ready to go live.

This also means automating some manual steps, such as enabling the process to manage all the security steps for you (e.g. checking, signing, uploading). This can help the deployment run smoothly and improve collaboration between the development and the business teams.

However, CD could also refer to Continuous Deployment, which is a continuous process from creation to production.

In this case, the pipelines will automatically deploy each new version of your application into production after it is passed through checking gates.

Whatever you want to do with your pipelines, you will need to define requirements and processes across all the different teams involved.

Tools such as GitHub Actions, Gitlab CI and Jenkins help you to build these pipelines and integrate them into your CI. Here I will mostly focus on GitHub Actions.

Automate your processes with Github Actions

GitHub Actions is a feature provided by GitHub teams to automate development lifecycles. It’s available out-of-the-box with any GitHub repository.

GitHub Actions Components

GitHub Actions Components use Events to trigger specific processes.

According to the GitHub Actions naming nomenclature, an Event triggers Workflows composed of Jobs, which execute Steps on Runners. Within a Step, you can execute Actions, which are the smallest components of the GitHub Action framework.

Runners are servers hosted by GitHub (Ubuntu Linux, Microsoft Windows, or macOS), or even your private Runners. It is useful to reuse existing servers or switch to a specific environment.

Create your first Workflow

GitHub Actions Workflows are based on Yaml files that you have to declare in the .github/workflows folder at the root project level, then commit and push to your Git repository.

Here is an example of a Workflow I have in some of my Monolith sample applications.

name: Application CI
on: [push]
jobs:
run-tests:
 runs-on: ubuntu-latest
 steps:
   - uses: actions/checkout@v2
   - uses: actions/setup-node@v1
     with:
       node-version: 12.18.3
   - uses: actions/setup-java@v1
     with:
       java-version: '11.x'
   - name: Install node.js packages
     run: npm install
   - name: Run backend tests
     run: |
         chmod +x mvnw
         ./mvnw -ntp clean verify -P-webpack
   - name: Run frontend tests
     run: npm run test

• The name is optional, but I recommend assigning an appropriate name to have a better overview of your Workflows in your GitHub Actions tab.
• on defines Events to trigger the Workflow. In our example, the Workflow will trigger each time a new commit is pushed on any branch of our application.
• jobs consists of the Job list contained in this Workflow. We have included one Job, run-tests in our Job list.
• runs-on defines the kind of Runner you want the Workflow to run on. Here we’ve selected the last available Ubuntu version.
• steps defines the list of Steps the Job will execute. Our Steps can either use existing Actions or only run simple bash commands. Using with in an existing Action allows us to pass parameters.

To summarize, this Workflow will be triggered each time a new commit is pushed on any branch, execute a Job named “run-tests” on a Ubuntu server, and perform this sequence of Steps:

1. Checkout the project
2. Install NodeJS using the dedicated Action
3. Install Java using the dedicated Action
4. Run the npm install command
5. Use Maven to run the backend tests
6. Use npm to run the frontend tests

You can learn more about this in the official documentation.

The GitHub Actions Marketplace

If you want to improve your Workflows by reusing Actions provided by the community, the marketplace is the place to visit.

The Actions can be created by the official Actions account, by organizations, individuals, or companies. Calling an Action can help you to execute a specific step instead of writing the commands yourself.

Leveraging Actions is a great way to easily set up your environment (e.g. install a JDK), integrate popular tools such as Docker and Ansible, or call a third-party solution (e.g. Create an issue on Jira).

When you are comfortable with your Workflow definition, I’d recommend checking the Marketplace to explore how to simplify the Yaml file, make the workflow more readable, and reuse existing Actions.

Plan and pricing

GitHub Actions is free with public repositories. That means you have unlimited automation minutes, while private repositories limit minutes to 2000 per month. Upgrading to a paid plan will grant you access to more minutes for your private repositories (3000 and 50,000 for Teams and Enterprise plans, respectively), and also include more package storage.

You can find more information on this page.

Regarding the usage, some limitations are applied to avoid using too much bandwidth with your Workflow:

• A Job can’t run continuously for more than 6 hours; the execution is halted when this limit is reached.
• A Workflow can’t run continuously for more than 72 hours; the execution is halted when this limit is reached.
• API requests are limited to 1000 calls per hour across a repository.
• Concurrent jobs are limited by plan, from 20 (free) to 180 (Enterprise). Please note for MacOS Runners you are limited from 5 to 50.
• Any job launched after the limit is reached will be placed in a queue.
• The queue can’t host more than 500 jobs in a 10-second interval.

What’s next

This is a good first step into the world of GitHub Actions. We’ve presented the CI/CD concepts, the GitHub Actions overall operation, how to define a good first Workflow, and limitations.

The next blog post will cover a real-world example of how we can create a Workflow based on a real-world project using the Entando Standard Banking Demo.