Everything you need to know about getting started with GitHub Actions

GitHub Actions help you automate your software development workflows in the same place you store and collaborate on code. Individual actions are reusable pieces of code that let you build, test, package, or deploy projects on GitHub. But you can also use them to automate any step of your workflow.

How to get started in four simple steps

1. Click the “Actions” tab in your repository
   GitHub Actions is tightly integrated with your code and with the rest of the experiences on GitHub.
2. Choose the workflow that’s best for your type of project
   GitHub Actions offers helpful workflow templates to get you started, including templates for Node.js, Rust, .NET Core, and more.
3. Customize your workflow
   You can start with the workflow templates that we provide, and then you can customize them to your project’s exact requirements.
4. Once you’ve chosen your workflow, press the “start commit” button
   Your workflow configuration lives in your repository, so the build definition is versioned alongside the finished code.

GitHub Actions guide: https://help.github.com/en/actions
Questions and answers on GitHub Actions: github.community

Helpful terms to know

Action
A program that becomes a reusable component to be used in workflows. Actions can install software for the environment, set up authentication, or automate complex sets of tasks. You can find actions in the GitHub Marketplace, or create your own and share them with your community.

Workflow
A configurable, automated process that you can use in your repository to build, test, package, release, or deploy your project. Workflows are made up of one or more “jobs” and can be triggered by GitHub events.

Continuous integration (CI)
The software development practice of frequently committing small code changes to a shared repository. With GitHub Actions, you can create custom CI workflows that automatically build and test your code. From your repository, you can view the status of your code changes and detailed logs for each action in your workflow. CI saves developers time by providing immediate feedback on code changes to detect and resolve bugs faster.

YAML
YAML stands for “Yet Another Markup Language”. It’s a human-readable markup language commonly used for configuration files, especially by CI- and DevOps-focused software tools. GitHub Actions uses YAML as the basis of its configuration workflows.

Workflow file
The configuration file that defines your GitHub Actions workflow. This is written in YAML and lives inside your GitHub repository in the .github/workflows directory. Each file in that directory that is named with a .yaml extension will define a unique workflow.

Example workflow file

name: CI for Node.js Project
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]
jobs:
  build:
    runs-on: ubuntu-latest
    name: Build and Test
    steps:
    - uses: actions/checkout@v2
      name: Check out repository
    - uses: actions/setup-node@v1
      name: Set up Node.js
      with:
        node-version: 12
    - run: |
        npm ci
        npm run build
        npm test
      name: Build and Test

An explanation of this example workflow:

name
The name of your workflow will be displayed on your repository’s actions page.

on
The events that occur on GitHub that will cause your workflow to be executed. For example, you can run your workflow on push and pull_request triggers, which will let you build your code and run your tests in a Continuous Integration workflow. You can add additional constraints on these triggers, like running when certain files or changed or when a certain branch is pushed to.

jobs
A list of the jobs that run as part of the workflow. Each job will run independently of the others, and will run on a different virtual environment. Jobs may have a name to make them easily identifiable in the UI or in logs. Jobs contain a set of steps that will be executed, in order. This workflow has a single job, the build job.

jobs.<job-id>.runs-on
The type of runner to use to run the given job on, either a runner provided by GitHub or a self-hosted runner that you configure. GitHub provides three main types of runners: Linux (named ubuntu-latest), Windows (named windows-latest) and macOS (named macos-latest).

jobs.<job-id>.steps
A list of the steps that will run as part of the job. Each step will run one after another, all on the same virtual environment. By default, if any step fails then the entire job will stop. In this workflow, the build job contains three steps:

1. The first step uses an action named actions/checkout@v2. This is an action provided by GitHub that will check out your repository onto the runner, so that it can be built and tested.
2. The second step uses an action named actions/setup-node@v1. This is an action provided by GitHub that will set up a particular version of Node.js on the runner. Arguments can be provided to the action in the with section; in this example, the node-version argument is set to 12, which instructs the action to put Node.js version 12 in the PATH for subsequent steps.
3. The final step runs programs on the command-line. By default, these programs will be run with bash (on Linux and macOS) or PowerShell (on Windows). A single command may be specified, or multiple commands can be specified by starting them with a leading pipe (|) symbol.
   
   In this case, a Node.js continuous integration build will be performed by running npm ci to download and install packages from the npm registry, then running npm run build to run the build script specified by the project, and finally running npm test to run any unit tests in the project.

See all whitepapers →