A workflow is an automated procedure that exists as a part of our repo.

• Workflows are made up of a collection of jobs which run is response to some event (on PR, on push etc)

A Github Workflow can be used to build, test, package, release, or deploy a project on GitHub.

Workflows can be configured to run in response to a webhook call, so we can trigger workflows in response to events happening outside Github.

Resources

• Workflow Syntax Guide

A job is a set of steps that execute on a single runner

A workflow with multiple jobs will run those jobs in parallel by default (configurable)

Each job in a workflow runs in a fresh virtual environment

A step is an individual task that can run commands in a job

A step can either be:

• a shell command
• an action

Each step in a job executes on the same runner, allowing the actions in that job to share data with each other.

Changing directories in one step does not carry through to the next step:

# workflow.actions.yml
    - name: cd into publishable
      run: |
        cd publishable 
        pwd

    - name: does the cd carry thru?
      run: |
        pwd

log:

Run cd publishable
/home/runner/work/Digital-Garden/Digital-Garden/publishable

Run pwd
/home/runner/work/Digital-Garden/Digital-Garden

Actions are standalone commands that are combined into steps to create a job Actions are the smallest portable building block of a workflow. You can create your own actions, or use actions created by the GitHub community

For instance, we have the checkout@v2 action, which allows the runner to checkout a repo. In fact, we can checkout any SHA from any repo.

A runner is a server that has the GitHub Actions runner application installed

• meaning we could use the managed service from Github, or self-host the Runner.

A runner listens for available jobs, runs one job at a time, and reports the progress, logs, and results back to GitHub

GitHub-hosted runners are based on Ubuntu Linux, Microsoft Windows, and macOS