GitHub Actions – fully integrated and shareable

GitHub Actions are around for some time now. Many have heard about them but not everyone was able to play with them as they were in private beta. After some months this has finally changed. GitHub Actions are now GA (General Availability) and everyone can use them.

But what exactly are GitHub Actions and what can I do with them?

Actions is a CI/CD (Continuous Integration / Continuous Delivery) platform by GitHub. Actions is fully integrated with the existing GitHub features like code hosting, project management and documentation.

To use GitHub Actions we need to create a pipeline called Workflow. A Workflow is a manifest written in YAML which allows you to version and store them within your project repository. It’s also possible to define multiple Workflows within one repository.

Because you like to use Workflow to automate your processes it needs to trigger based on events. A big advantage of GitHub Actions is that you can trigger Workflows with nearly every event. You know events like commit, merge, pull request, but you can now also trigger your Workflows on a Wiki update, an added Label, after a Milestone close or an edited Pull request. Nearly anything is possible!

As mentioned above a Workflow contains multiple parts:

Step

A step is the smallest instance in a Workflow. It contains out of one or multiple lines of commands.

Action

Actions are like Steps but sharable. Because of this they can be more complex and can be used for generic tasks like secret management or init tasks.

Jobs

One or multiple Steps and Actions can be combined in Jobs. The job also defines the sequence in which the jobs should be processed on which Runner.

Workflow

As already mentioned above, a Workflow is the biggest instance of GitHub Actions. It contains one or multiple Jobs as well as the trigger definition.

Let me follow up on Actions – the reusable and sharable “Steps”. To make them even more useful GitHub introduced the GitHub Marketplace. The Marketplace can be used to search for existing Actions as well as publish your Actions to share them with others.

 

You can access the GitHub Marketspace here.

The definition of your Workflow is one part, the other is the actual compute needed to run them. With GitHub Actions you have two different options:

GitHub-hosted Runner

The hosted Runners are the fastest and easiest option to get started. You have access to Linux, Windows and Mac Runners. Based on your GitHub plan you also have some limitations you have to live with. For the free plan, those are 20 concurrent jobs and 5 concurrent macOS jobs. Besides the plan limits there are also the following hard limits:

  • 20 concurrent Workflows per repository
  • 1000 API requests per repository and hour
  • 6h runtime limit for Workflows

Further details about the runner itself as well as the installed software are available here and here.

Self-hosted Runner

Besides the hosted Runner, you also have the option to use your own compute as a Runner. Self-hosted Runners are still in Beta. As soon as they are released the allow much more flexibility without any limits. Supported Operating Systems are:

  • Ubuntu
  • RedHat Enterprise Linux
  • CentOS
  • Fedora
  • Mint
  • openSUSE
  • SLES
  • Windows 7, 8.1, 10
  • Windows Server 2016, 2019
  • macOS

How to start?

This repository contains a ton of useful Workflow examples which are ready to use: https://github.com/actions/starter-workflows/tree/master/ci

The below example is based on the Azure Workflow (you will find it in the linked repository). It’s chopped up so we can walk through the steps one by one.

on:
  push:
    branches:
      - master

First of all, we define that this Workflow is only triggered by a push in the master branch. 

env:
  AZURE_WEBAPP_NAME: your-app-name 
  AZURE_WEBAPP_PACKAGE_PATH: '.'     
  NODE_VERSION: '10.x'

In this step, we define some global environment parameters which we use in later steps.

jobs:
  build-and-deploy:
    name: Build and Deploy
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: Use Node.js ${{ env.NODE_VERSION }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ env.NODE_VERSION }}

In the above step, we defined our first “build-and-deploy” job which calls two different Actions. The first one, to check out our code, the second one to set up the node environment.

  - name: npm install, build, and test
      run: |
        # Build and test the project, then
        # deploy to Azure Web App.
        npm install
        npm run build --if-present
        npm run test --if-present
    - name: 'Deploy to Azure WebApp'
      uses: azure/webapps-deploy@v1
      with:
        app-name: ${{ env.AZURE_WEBAPP_NAME }}
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

In the last part we call a Step called “npm install, build, and test” followed by an Action to deploy our app to Azure WebApp.

More details on GitHub Actions are available here.

Feel free to join our next Azure Rosenheim Meetup where we will provide a detailed GitHub Actions 101 talk including demos. You can register here.