Actions Cheat Sheet

GitHub Actions give you the flexibility to build automated software development lifecycle workflows. You can write individual
tasks, called actions, and combine them to create custom workflows in your repository. GitHub Actions are automated
processes allowing you to build, test, package, release, or deploy any code project on GitHub, but you can also use them to
automate any step of your workflow: merging pull requests, assigning labels, triaging issues to name a few.

Workflow Syntax on Event

Workflow files use YAML syntax, and must have either a .yml The type event that triggers the workflow. You can provide a
or .yaml file extension. You must store workflow files in the single event string, an array of events, or an event
.github/workflows/ directory of your repository. Each configuration map that restricts the execution of a workflow:
different YAML file corresponds to a different workflow. When using the push and pull_request events, branches
and tags allow to select or exclude (with the ! prefix) git
name: My Workflow
references the workflow will run on, while paths specifies
on:
which files must have been modified in order to run the
workflow.
push:
branches:
- 'releases/*' If your rules are only made of exclusions, you can use
- '!releases/**-alpha' branches-ignore, tags-ignore and paths-ignore. The -
env: ignore form and its inclusive version cannot be mixed.
message: 'conversation' The types keyword enables you to narrow down activities
my_token: ${{ secrets.GITHUB_TOKEN }}
(opened, created, edited…) causing the workflow to run.
jobs:
The list of available activities depends on the event.
my_build:
runs-on: ubuntu-latest A workflow trigger can also be scheduled:
steps:
on:
- name: Checking out our code schedule:
uses: actions/checkout@master
- cron: '*/15 * * * *'
- name: Say something
run: |
jobs Collection
echo "A little less ${message}"
A workflow run is made up of one or more jobs identified by a
unique job_id (my_build or my_job). Jobs run in parallel by
echo "A little more action"
my_job:
needs: my_build default unless queued with the needs attribute. Each job runs
container: in a fresh instance of the virtual environment specified by
image: node:10.16-jessie runs-on.
env:
Job name
The name of the job displayed on GitHub.
NODE_ENV: development
ports:
- 80 needs
volumes:
Identifies any job that must complete successfully before this
- my_docker_volume:/volume_mount
job will run. It can be a string or array of strings. If a job fails,
options: --cpus 1
all jobs that need it are skipped unless the jobs use a
services:
redis: conditional statement that causes the job to continue.
image: redis runs-on
ports: The type of virtual host machine to run the job on. Can be
- 6379/tcp either a GitHub or self-hosted runner. Jobs can also run in
Workflow name user-specified containers (see: container). Available GitHub-
hosted virtual machine types are ubuntu-latest, windows-
The name of your workflow will be displayed on your latest, macOS-latest plus some other specific versions for
repository’s actions page. each operating system, in the form of ubuntu-xx.xx, macOS-
Workflow, Job or Step env xx.xx or windows-xxxx. To specify a self-hosted runner for
A map of environment variables which can be set at different your
hosted
job, configure runs-on in your workflow file with self-
runner labels. Example: [self-hosted, linux].
scopes. Several environment variables are available by default
(GITHUB_SHA, GITHUB_REF, GITHUB_EVENT_NAME, HOME,
GITHUB_EVENT_PATH…) as well as a secret, GITHUB_TOKEN,
which you can leverage for API calls or git commands through
the secrets context.
 Actions Cheat Sheet
container run
Instead of running directly on a host selected with runs-on, Instead of running an existing action, a command line program
a container can run any steps in a job that don’t already can be run using the operating system’s shell. Each run keyword
specify a container. If you have steps that use both script and represents a new process and shell in the virtual environment. A
container actions, the container actions will run as sibling specific shell can be selected with the shell attribute. Multiple
containers on the same network with the same volume commands can be run in a single shell instance using the |
mounts. This object has the following attributes: image, env, (pipe) operator.
ports, volume and options.
Job strategy
The maximum number of minutes to let a workflow run before Avirtual
build matrix strategy is a set of different configurations of the
timeout-minutes

GitHub automatically cancels it. Default: 360 environment. The job’ set of steps will be executed on
each of these configurations. The following exemple specifies 3
services nodejs versions on 2 operating systems:
Additional containers to host services for a job in a workflow. runs-on: ${{ matrix.os }}
These are useful for creating databases or cache services. strategy:
The runner on the virtual machine will automatically create a matrix:
network and manage the lifecycle of the service containers.
Each service is a named object in the services collection os: [ubuntu-16.04, ubuntu-18.04]
(redis or nginx for example) and can receive the same steps: node: [6, 8, 10]

parameters than the container object. - uses: actions/setup-node@v1

Job steps with:

node-version: ${{ matrix.node }}
A job contains a sequence of tasks called steps. Steps can
run commands, run setup tasks, or run an action from your fail-fast
repository, a public repository, or an action published in a When set to true (default value), GitHub cancels all in-progress
Docker registry. Each step runs in its own process in the jobs if any of the matrix job fails.
virtual environment and has access to the workspace and
filesystem. Context and expressions
Step name Expressions can be used to programmatically set variables in
Specify the label to be displayed for this step in GitHub. It’s workflow
combination
files and access contexts. An expression can be any
of literal values, references to a context, or
not required but does improve readability in the logs. functions. You can combine literals, context references, and
Specify an action to run as part of a step in your job. You can expressions are operators.
functions using With the exception of the if key,
uses

use an action defined in the same repository as the workflow, objects providing access to aruntime
written in ${{ … }} block. Contexts are
information. The following
a public repository elsewhere on GitHub, or in a published objects are available: github, job, steps , runner, secrets,
Docker container image. Including the version of the action strategy and matrix.
you are using by specifying a Git ref, branch, SHA, or Docker
tag is strongly recommended: Artifact storage & Caching
uses: {owner}/{repo}@{ref} for actions in a public An artifact is a file or collection of files produced during a
repository workflow run that can be stored and shared between jobs in a
uses: {owner}/{repo}/{path}@{ref} for actions in a workflow run. Use actions actions/upload-artifact and
subdirectory of a public repository actions/download-artifact with parameters name and path
uses: ./path/to/dir for actions in a a subdirectory of to manipulate artifacts. Artifacts can be downloaded through the
the same repository Web interface for 90 days.
uses: docker://{image}:{tag} for actions on Docker For dependencies and other commonly reused files across runs
Hub of a given workflow, use the actions/cache action with
uses: docker://{host}/{image}:{tag} for actions in parameters:
a public registry key: The key used to save and search for a cache.
with path: The file path (absolute or relative to the working
A map of the input parameters defined by the action in its directory) on the runner to cache or restore.
action.yml file. When the acion is container based, special restore-keys: Optional - An ordered list of alternative keys
parameter names are: to use for finding the cache if no cache hit occurred for key.
args, a string that defines the inputs passed to a Docker
container’s ENTRYPOINT. It is used in place of the CMD -- uses: actions/checkout@v1
instruction in a Dockerfile. name: Cache node modules

entrypoint, a string that defines or overrides the

uses: actions/cache@v1

executable to run as the Docker container’s ENTRYPOINT.

with:
path: node_modules
if key: x-y-${{hashFiles('**/package-lock.json')}}
Prevents a step from running unless a condition is met. The restore-keys: |
value is an expression without the ${{ … }} block. x-y-
x-

Enterprise Find Actions on GitHub Marketplace at github.com/marketplace

Bring GitHub to work, on-premises or in the cloud Read about GitHub Actions at help.github.com/actions
Join a GitHub Learning Lab course at lab.github.com
https://enterprise.github.com