Automate your workflow with GitHub Actions

13 april 2020 om 09:44 by ParTech Media - Post a comment

In this article, we will introduce you to GitHub Actions. Last year, some new GitHub features were introduced. Amongst them was GitHub Actions.

GitHub Actions enables continuous integration and a wide range of automation configured from within your repository. You can create your own actions, use and customize actions shared by the GitHub community, or write and share the actions you build. To share actions you've built, your repository must be public.

GitHub Actions supports Windows, Linux and MacOS and you can run any programming language supported by these operating systems.

Let's take a look at the core concepts of GitHub Actions and some examples to create your own custom workflows.

Automate workflows

Automation is achieved by defining workflows. A workflow consists of one or more tasks which are called actions. These actions can be run automatically on certain events.

You can create actions by writing custom code that interacts with your repository as well as integrating with GitHub's APIs and any publicly available third-party API. For example, an action can run npm modules, send SMS alerts when crucial issues are created, or deploy production-ready code.

Actions can run directly on a machine or in a Docker container. You can define an action's inputs, outputs, and environment variables.

Benefits

GitHub Actions:

  • Can run directly on runner machines or in Docker containers.
  • Can include access to a clone of your repository, allowing deployment and publishing tools, code formatters, and command line tools to access your code.
  • Offer automation that can complete continuous integration and continuous deployment.
  • Does not require you to deploy code or serve an app.
  • Has a simple interface to generate and use secrets, that allows actions to interact with third-party services without storing the credentials of the person using the action.

Types of GitHub Actions

Actions require a metadata file to define the inputs, outputs and main entry-point for your action. The metadata filename must be either action.yml or action.yaml. You can build Docker container and JavaScript actions.

Docker containers package the environment with the GitHub Actions code. This creates a further dependable and consistent unit of work because the consumer of the action need not be concerned about the tools or dependencies. Docker container actions can only execute in the GitHub-hosted Linux environment.

JavaScript actions can run directly on a runner machine and separate the action code from the environment used to run the code. Using a JavaScript action makes the action code simpler and executes quicker than a Docker container action.

Core concepts

An overall understanding of some prominent core concepts used in GitHub Actions is given below.

Actions

Actions are the smallest portable building block of a workflow and can be combined as steps to create a job. You can create your own actions or use and customize publicly shared actions from the by the GitHub community.

Event

Events are specific activities that trigger a workflow run. For example, a workflow is triggered when somebody pushes to the repository or when a pull request is created. Events can also be configured to listen to external events using Webhooks.

Runner

A runner is a machine with the GitHub Actions runner application installed. The runner waits for available jobs that it can then execute. After picking up a job, it runs the job's actions and reports the progress and outcomes back to GitHub. Runners can be hosted on GitHub or self-hosted on your own machines/servers.

Job

A job is made up of multiple steps and runs in an instance of the virtual environment. Jobs can run independently of each other or sequential if the current job depends on the previous job to be successful.

Step

A step is a set of tasks that can be executed by a job. Steps can run commands or actions.

Workflow

Workflows are custom automated processes that you can set up in your repository to build, test, package, release, or deploy any project on GitHub. Workflows are defined using a yaml file in the .github/workflows directory in your repository.

GitHub Actions Examples

GitHub Actions make it simple to roll-out an extensive variation of DevOps automation task. The examples given below depict CI/CD and automation using GitHub Actions.

Example 1: Continuous Integration

Continuous Integration (CI) automates the process of testing and building your code before merging it. As a practice, developers must commit or integrate their changes to the main shared repository once per day or more (if required).

.github/workflows/workflow.yml

name: Node Continuous Integration

on:
  pull_request:
    branches: [ master ]

jobs:
  test_pull_request:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 12
      - run: npm ci
      - run: npm test
      - run: npm run build

Source: https://fireship.io/lessons/five-useful-github-actions-examples/

Example 2: Publish Package to NPM on Release

If you maintain an open source package then it can be monotonous to republish your package after making a new release. You can use the workflow given below to automatically publish a package to NPM or GitHub Package Registry.

.github/workflows/workflow.yml

name: Sveltefire Package

on:
  release:
    types: [created]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 12
      - run: npm ci
      - run: npm test

  publish-npm:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 12
          registry-url: https://registry.npmjs.org/
      - run: npm ci
      - run: npm build
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{secrets.npm_token}}

  publish-gpr:
    needs: build
    runs-on: ubuntu-lates
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 12
          registry-url: https://npm.pkg.github.com/
          scope: '@your-github-username'
      - run: npm ci
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}

Source: https://fireship.io/lessons/five-useful-github-actions-examples/

Example 3: Send Email or Chat Messages

To post data from GitHub to a chat or an email service, like Slack.

.github/workflows/workflow.yml

name: Slack Issues

on:
  issues:
    types: [opened]

jobs:
  post_slack_message:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: rtCamp/[email protected]
    env:
      SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
      SLACK_USERNAME: CyberJeff 
      SLACK_CHANNEL: gh-issues

Source: https://fireship.io/lessons/five-useful-github-actions-examples/

Conclusion

You can use GitHub Actions to automate your GitHub workflow. GitHub Actions involve minimal configuration for use, for example - A simple button on your GitHub repository page triggers the configuration of a CI/CD pipeline and this lets the developer to emphasize on development instead of setting up the servers for Jenkins or signing up other vendors like CircleCI.

Nieuwste