What Is “GitHub Actions”?

A Work ow Automation Service by GitHub

Automate all kinds of repository-

related processes & actions

Code Deployment
Code & Repository Management
(CI / CD)

Automate code testing, building & Automate code reviews, issue

deployment management etc.
fl

What is GitHub?
And what are “repositories”?
What’s CI / CD?

Continuous Integration Continuous Delivery

Methods for
automating app
development &
deployment

Code changes are After integration, new app or

automatically built, tested & package versions are
merged with existing code published automatically
 A Typical CI / CD Workflow

Code was changed

(e.g, new feature added)

Can be con gured & executed

via GitHub Actions
New Git Commit

CI / CD Work ow

Pushed to GitHub App is tested App is published

App is built
Repository (e.g., unit tests) (e.g., on AWS EC2)
fi
fl

 GitHub Actions Alternatives

GitHub Actions

For CI / CD

Alternatives

Jenkins GitLab CI/CD Azure Pipelines AWS CodePipeline

and many more …

What is Git?
What Is GitHub?

A cloud Git repository & services

provider

Store & manage Git repositories

 What Is Git?

A (free) version control system

A tool for managing source code changes

Save code snapshots Work with alternative code Move between branches &
(“commits”) versions (“branches”) commits

With Git, you can easily roll back to older code snapshots or
develop new features without breaking production code.
 What Is GitHub?

A cloud Git repository & services

provider

Store & manage Git repositories

Cloud Git repository storage Code management &

Automation & CI / CD
(“push” & “pull”) collaborative development

Backup, work across Via “Issues”, “Projects”, “Pull Via GitHub Actions, GitHub
machines & work in teams Requests” & more Apps & more

Public & private, team

management & more
 About This Course

Learn GitHub Actions From The Ground Up

Video-based
Practice & Experiment Learn & Grow Together
Explanations

Pause videos and practice on Help each other in the course

Watch the videos—at your pace
your own Q&A section

Recommendation: Watch all Build up on course examples &

Dive into our (free!) community
videos in the provided order feel free to experiment

Build your own demo projects &

Repeat videos as needed
work ow examples
fl
 Git & GitHub Crash Course
The Very Basics

Working with Git: Setup & Key Commands

Working with GitHub: Creating & Using Repositories

Using Git with GitHub

 What Is Git?

A (free) version control system

A tool for managing source code changes

Save code snapshots Work with alternative code Move between branches &
(“commits”) versions (“branches”) commits

With Git, you can easily roll back to older code snapshots or
develop new features without breaking production code.
Git Repositories

Git features can be used in projects

with Git repositories

A repository is a folder used by Git to Git commands require a

track all changes of a given project repository in a project

Only required once per

Create Git repositories via git init
folder / project

Some projects initialize Git for you e.g., React projects

 Working with Commits (Code Snapshots)

Create Commits Move between Commits

git add <file(s)> git checkout <id>

Stage changes for next Temporarily move to

commit another commit

git commit

Create a commit that

includes all staged changes HEAD

C1 C2 C3 C4 C5 C6
 Working with Commits (Code Snapshots)

Create Commits Move between Commits

git add <file(s)> git checkout <id>

Stage changes for next Temporarily move to

commit another commit

git commit

Create a commit that

includes all staged changes HEAD

C1 C2 C3 C4 C5 C6
Understanding Staging

Staging controls which changes are

part of a commit

With staging, you can make sure that

not all code changes made are added
to a snapshot

If all changes should be included, you

can use git add . to include all les
in a Git repository

fi
 Working with Commits (Code Snapshots)

Create Commits Move between Commits

git add <file(s)> git checkout <id>

Stage changes for next Temporarily move to

commit another commit

git commit

Create a commit that

includes all staged changes HEAD

C1 C2 C3 C4 C5 C6
 Working with Commits (Code Snapshots)

Create Commits Move between Commits Undo Commits

git add <file(s)> git checkout <id> git revert <id>

Stage changes for next Temporarily move to Revert changes of commit

commit another commit by creating a new commit

git commit

Create a commit that

includes all staged changes HEAD

C1 C2 C3 C4 C5 C6
 Working with Commits (Code Snapshots)

Create Commits Move between Commits Undo Commits

git add <file(s)> git checkout <id> git revert <id>

Stage changes for next Temporarily move to Revert changes of commit

commit another commit by creating a new commit

git commit

Create a commit that

includes all staged changes HEAD

C1 C2 C3 C4 C5 C6 C7
 Working with Commits (Code Snapshots)

Create Commits Move between Commits Undo Commits

git add <file(s)> git checkout <id> git revert <id>

Stage changes for next Temporarily move to Revert changes of commit

commit another commit by creating a new commit

git reset --hard <id>

git commit Undo changes by deleting all

commits since <id>
Create a commit that
includes all staged changes HEAD

C1 C2 C3 C4 C5 C6
 Working with Commits (Code Snapshots)

Create Commits Move between Commits Undo Commits

git add <file(s)> git checkout <id> git revert <id>

Stage changes for next Temporarily move to Revert changes of commit

commit another commit by creating a new commit

git reset --hard <id>

git commit Undo changes by deleting all

commits since <id>
Create a commit that
includes all staged changes HEAD

C1 C2 C3 C4
 Key Commands

git init Initialize a Git repository (only required once per project)

git add <file(s)> Stage code changes (for the next commit)

git commit -m “…” Create a commit for the staged changes (with a message)

git status Get the current repository status (e.g., which changes are staged)

git log Output a chronologically ordered list of commits

git checkout <id> Temporarily move back to commit <id>

git revert <id> Revert the changes of commit <id> (by creating a new commit)

git reset <id> Undo commit(s) up to commit <id> by deleting commits

Understanding Git Branches
main

Create a new branch

C1 git branch <name>
feature-1

C2 C2

Merge branches
C3
git merge <name>

C4 C4
 What Is GitHub?

A cloud Git repository & services

provider

Store & manage Git repositories

Cloud Git repository storage Code management &

Automation & CI / CD
(“push” & “pull”) collaborative development

Backup, work across Via “Issues”, “Projects”, “Pull Via GitHub Actions, GitHub
machines & work in teams Requests” & more Apps & more

Public & private, team

management & more
GitHub Repositories
Backup, cross-device
Cloud storage for your Git repositories
usage, collaboration

Public Private

“Connected” to local Git repositories via git remote add

Local commits are uploaded via git push

Remote commits are downloaded via git pull

Forking & Pull Requests

Repository Forking Pull Requests

Creates a standalone copy of Requests merging code

a repository changes into a branch

Can be used to work on code Can be based on a forked

without a ecting the original repository or another branch
repository from the same repository

Pull requests allow for code

reviews before merging
changes
ff
 GitHub Actions: Fundamentals
Key Building Blocks & Usage

Understanding the Key Elements

Working with Work ows, Jobs & Steps

Building an Example Work ow

fl
fl
 Key Elements

Work ows Jobs Steps

Attached to a GitHub De ne a Runner (execution Execute a shell script or an

repository environment) Action

Can use custom or third-

Contain one or more Jobs Contain one or more Steps
party actions

Run in parallel (default) or

Triggered upon Events Steps are executed in order
sequential

Can be conditional Can be conditional

fi
fl
 Workflows, Jobs & Steps
Code Repository

Work ow 1 Work ow 2 Work ow 3

Job 1 Job 1 Job 1

Step 1 Step 1 Step 1

Step 2 Step 2
Step 3
Job 2 Step 4 Job 2

Step 1 Step 1
fl
fl
fl
 Events (Workflow Triggers)

Repository-related Other

push pull_request create work ow_dispatch

Pushing a commit Pull request action A branch or tag was Manually trigger
(opened, closed, …) created work ow

fork issues issue_comment repository_dispatch

Repository was An issue was opened, Issue or pull request REST API request
forked deleted, … comment action triggers work ow

schedule
watch discussion Work ow is scheduled
Repository was Discussion action Many More!
starred (created, deleted, …)

work ow_call
Can be called by other
work ows


fl
fl


fl
fl
fl










fl










 What Are Actions?
Command
Action
(“run”)

A (custom) application that

A (typically simple) shell command
performs a (typically complex)
that’s de ned by you
frequently repeated task

You can build your own Actions but

you can also use o cial or
community Actions
fi

ffi
 Job Runners
Every job has a Runner
Work ow Job

Runner
Steps execute
on the Runner Server (virtual
machine) that runs
the job
Steps
GitHub provides
Ubuntu Linux,
Windows & macOS
Runners

You can also host and

use your own runner
fl
 Module Summary

Core Components Events / Triggers Work ow Execution

Broad variety of events Work ows are executed when

Work ows: De ne Events + Jobs
(repository-related & other) their events are triggered

Work ows have at least one (but GitHub provides detailed insights
Jobs: De ne Runner + Steps
possible more) event(s) into job execution (+ logs)

Steps: Do the actual work

Runners Actions

De ning Work ows Servers (machines) that execute

You can run shell commands
the jobs

.github/work ows/< le>.yml Pre-de ned Runners (with But you can also use pre-de ned
(on GitHub or locally) di erent OS) exist Actions (o cial, community or
custom)
GitHub Actions syntax must be You can also create custom
followed Runners
ff
fi
fl
fl
fl
fl
fi
fi
ffi
fl
fi
fl
fi
fi

Exercise Time!
Use the Attached
Project

Create 2 Work ows

Lint, Test & Deploy on Output Event Details on

“push” “issues”

Run the “lint”, “test” & Output event details in the

“build” scripts shell via “echo”

Use one or three jobs Use the “issues” event &

(running after each other) “github” context
fl
 Events: A Closer Look
Diving Deeper Into Workflow Triggers

Controlling Work ow Execution with Event Filters

Detailed Control with Activity Types

Examples!
fl
 Available Events

Repository-related Other

push pull_request create work ow_dispatch

Pushing a commit Pull request action A branch or tag was Manually trigger
(opened, closed, …) created work ow

fork issues issue_comment repository_dispatch

Repository was An issue was opened, Issue or pull request REST API request
forked deleted, … comment action triggers work ow

schedule
watch discussion Work ow is scheduled
Repository was Discussion action Many More!
starred (created, deleted, …)

work ow_call
Can be called by other
work ows


fl
fl


fl
fl
fl










fl










 Event Activity Types & Filters

Event e.g., push, pull_request

Some events have

Activity Types Filters

More detailed control over when a More detailed control over when a
work ow will be triggered work ow will be triggered

opened
Filter based
closed
pull_request Event push Event on target
edited
branch
…
fl
fl

A Note About Fork Pull Request Workflows

By default, Pull Requests based on

Forks do NOT trigger a work ow

Reason: Everyone can fork &

open pull requests

Malicious work ow runs &

excess cost could be caused

First-time contributors must be

approved manually
fl
fl
 Cancelling & Skipping Workflow Runs

Cancelling Skipping

By default, Work ows get By default, all matching

cancelled if Jobs fail events start a work ow

By default, a Job fails if at Exceptions for “push” &

least one Step fails “pull_request”

You can also cancel Skip with proper commit

work ows manually message
fl
fl
fl
 Module Summary

Available Events Activity Types Event Filters

The exact type of event that For push & pull_request: Add
There are many supported events
should trigger a work ow lters to avoid some executions

Most are repository-related (e.g., Examples: Opening or editing a Filter based on target branch and
push, pull_request) pull request should trigger the wf / or a ected le paths

But some are more general (e.g.,

schedule) Cancelling & Skipping

Pull Requests & Forks Work ows get cancelled

automatically when jobs fail

Initial approval needed for pull You can manually cancel

requests from forked repositories work ows

Avoids spam from untrusted You can skip via [skip ci] etc. in
contributors commit message
fi
fl
fl
ff
fi
fl
Exercise Time!

1 2

Test & Deploy For “main” Run Tests Upon Pull

Pushes & Manual Trigger Requests

Goal: Run Work ow if a Goal: Run Work ow if a

commit is pushed to the collaborator pull_request is
“main” branch opened

Ignore push events for other Only run for pull_requests

branches targeting the “main” branch

Variation
Also run for “dev” branch and Variation
DON’T run if work ow les Also run for “dev” branch
were edited

fl
fl
fl
fi
 Job Data & Outputs
It’s All About Data!

Working with Artifacts

Working with Job Outputs

Caching Dependencies
 Understanding Job Artifacts

Job Example: Build app

Example: App binary,

Output Asset(s)
website les etc.

Download & Use Download & Use in

Manually other Jobs

Via GitHub UI or REST

Via Action
API
fi
 Understanding Job Outputs

Artifacts Job Outputs

Output les & folders Simple values

Typically used for Typically used for re-

sharing log les, app using a value in di erent
binaries etc. jobs

Example: Name of a le
generated in a previous
build step
fi
fi
ff
fi
Caching Dependencies

Get Code Get Code

Install Dependencies Install Dependencies

Often repeated
Test App Build Project
Dependencies
don’t change
frequently
 Module Summary

Artifacts Outputs Caching

Jobs often product assets that Besides Artifacts, Steps can Caching can help speed up
should be shared or analyzed product and share simple values repeated, slow Steps

Examples: Deployable website These outputs are shared Typical use-case: Caching
les, logs, binaries etc. via ::set-output dependencies

These assets are referred to as Jobs can pick up & share Step But any les & folder can be
“Artifacts” (or “Job Artifacts”) outputs via the steps context cached

GitHub Actions provides Actions Other Jobs can use Job outputs The cache Action automatically
for uploading & downloading via the needs context stores & updates cache values
(based on the cache key)

Important: Don’t use caching for

artifacts!
fi
fi
Environment Variables & Secrets
Hardcoding Is Not (Often) The Solution

Understanding & Using Environment Variables

Using Secrets

Utilizing Job Environments

Understanding Environment Variables

Environment 1 Environment 2
“testing” “production”

const password = process.env.DB_PASSWORD

const password = 'abc' const password = ‘123'

Environment Variables vs Secrets

Some environment variable values

should never be exposed

Example: Database access password

Together with
Use Secrets
environment variables
 GitHub Repository Environments

GitHub Environments Attached to Repositories

Work ow Jobs can target

Environments

Di erent Con gurations Special protection rules

Di erent Secrets for di erent e.g., only events related to

environments (e.g., di erent certain branches can use an
database passwords) environment
ff
ff
fl
fi
ff
ff
 Module Summary

Environment Variables Secrets GitHub Actions Environments

Dynamic values used in code Some dynamic values should not Jobs can reference di erent
(e.g., database name) be exposed anywhere GitHub Actions Environments

May di er from work ow to Examples: Database credentials, Environments allow you to set up
work ow API keys etc. extra protection rules

Can be de ned on Work ow-, Secrets can be stored on You can also store Secrets on
Job- or Step-level Repository-level or via Environment-level
Environments
Can be used in code and in the
GitHub Actions Work ow Secrets can be referenced via the
secrets context object
Accessible via interpolation and
the env context object
fl
ff
fi
fl
fl
ff
fl
 Controlling Execution Flow
Beyond Step-By-Step Flows

Running Jobs & Steps Conditionally

Running Jobs with a Matrix

Re-Using Work ows

fl
Controlling Execution Flow
1
Get code (from repository)

2
Install dependencies

3
Lint code

4
Run automated tests

5
Upload report
Controlling Execution Flow
1
Get code (from repository)

2
Install dependencies

3
Lint code

4
Run automated tests

5
Upload report
Controlling Execution Flow
1
Get code (from repository)

2
Install dependencies

3
Lint code

4
Run automated tests

5
Upload report
 Conditional Jobs & Steps

Jobs Steps

Conditional execution via Conditional execution via

if eld if eld

Ignore errors via

continue-on-error eld

Evaluate conditions via Expressions

fi
fi
fi
 Special Conditional Functions

failure() success()

Returns true when none

Returns true when any
of the previous steps have
previous Step or Job failed
failed

always() cancelled()

Causes the step to always Returns true if the

execute, even when work ow has been
cancelled cancelled
fl
 Reusable Workflows

Work ow 1 Work ow 2

Job 1 Job 1

Steps Steps

Job 2

Work ow 1
Example: Upload website code to
hosting server
fl
fl
fl
 Module Summary

Conditional Jobs & Steps Matrix Jobs Reusable Work ows

Control Step or Job execution Run multiple Job con gurations in Work ows can be reused via the
with if & dynamic expressions parallel workflow_call event

Change default behavior with Add or remove individual Reuse any logic (as many Jobs &
failure(), success(), combinations Steps as needed)
cancelled() or always()
Control whether a single failing Work with inputs, outputs and
Use continue-on-error to Job should cancel all other Matrix secrets as required
ignore Step failure Jobs via continue-on-error
fl
fl
fi
 Using Containers
Utilizing Docker Containers

Containers - A Re-Introduction

Running Jobs in Containers

Using Service Containers

What Are Containers?

Docker Container

Packages that contain code + its

execution environment

Advantage: Reproducible
execution environment & results
Containers & GitHub Actions

still runs on

Docker Container GitHub Actions Runners

Your containerized Job is hosted

by the Runner

Steps execute inside the

Packages that contain code + its container
execution environment
You can also create Services:
Advantage: Reproducible Utility containers used by your
execution environment & results Steps (Example: Testing
Database)
 Why Use Containers?

Container Just the Runner

Choose from list of pre-

Full control over environment
de ned environments (incl.
& installed software
installed software)
fi
Using Service Containers (“Services”)

Job Service Container

Example: Hosts a testing

Example: Runs tests
database

Problem: Tests should not Runs inside a container

manipulate production (hosted by the Runner)
database
Job steps can communicate
with service containers (and
Solution: Use a testing
the services exposed by
database
them)
 Module Summary

Containers Containers for Jobs Service Containers

Packages of code + execution You can run Jobs in pre-de ned Extra services can be used by
environment environments Steps in Jobs

Great for creating re-usable Build your own container images Example: Locally running, isolated
execution packages & ensuring or use public images testing database
consistency
Based on custom images or
Example: Same environment for Great for Jobs that need extra public / community images
testing + production tools or lots of customization

fi
 Building Custom Actions
Beyond Shell Commands & The Marketplace

What & Why?

Di erent Types of Custom Actions

Building & Using Custom Actions

ff
 Why Custom Actions?

No Existing (Community)
Simplify Work ow Steps
Action

Instead of writing multiple

Existing, public Actions might
(possibly very complex) Step
not solve the speci c problem
de nitions, you can build and
you have in your Work ow
use a single custom Action

Multiple Steps can be grouped Custom Actions can contain

into a single custom Action any logic you need to solve
your speci c Work ow
problems
fi
fi
fl
fi
fl
fl
 Different Types of Custom Actions

{}
JavaScript Actions Docker Actions Composite Actions

Create a Docker le with your Combine multiple Work ow

Execute a JavaScript le
required con guration Steps in one single Action

Use JavaScript (NodeJS) + Perform any task(s) of your Combine run (commands)
any packages of your choice choice with any language and uses (Actions)

Pretty straightforward (if you Lots of exibility but requires Allows for reusing shared
know JavaScript) Docker knowledge Steps (without extra skills)
fl
fi
fi
fi
fl
 Module Summary

What & Why? Composite Actions JavaScript & Docker Actions

Simplify Work ows & avoid Create custom Actions by Write Action logic in JavaScript
repeated Steps combining multiple Steps (NodeJS) with @actions/toolkit

Implement logic that solves a Composite Actions are like Alternatively: Create your own
problem not solved by any “Work ow Excerpts” Action environment with Docker
publicly available Action
Either way: Use inputs, set outputs
Create & share Actions with the Use Actions (via uses) and and perform any logic
Community Commands (via run) as needed
fl
fl
 Permissions & Security
Keep Things Secure

Securing Your Work ows

Working with GitHub Tokens & Permissions

Third-Party Permissions
fl
 Security Concerns

Malicious Third-Party
Script Injection Permission Issues
Actions

A value, set outside a Actions can perform any

Consider avoiding overly
Work ow, is used in a logic, including potentially
permissive permissions
Work ow malicious logic

Example: A third-party Action

Example: Issue title used in a Example: Only allow checking
that reads and exports your
Work ow shell command out code (“read-only”)
secrets

Only use trusted Actions and

Work ow / command GitHub Actions supports ne-
inspect code of unknown /
behavior could be changed grained permissions control
untrusted authors
fl
fl
fl
fl
fi
 Using Actions Securely

Considerable
amount of Only use your own Actions Highest Level of Security
e ort

Still not a 100% Only use Actions by veri ed

guarantee! creators

You should
analyze the
Use all public Actions Lowest Level of Security
Action code
rst!
fi
ff
fi
 GitHub Permissions & GITHUB_TOKEN

Work ows run Job on Runners

Runners: Isolated, virtual machines

Why do they have access to your e.g., for checking out the
GitHub repository? code or inspecting issues

GitHub creates an authentication Valid for the duration of a

token (GITHUB_TOKEN) Work ow Job
fl
fl
 Third-Party Permissions
Especially for deployment tasks, GitHub
Work ows regularly communicate with third-
party cloud / hosting providers

Credentials / Authentication required

Option 1: API or Access Keys Option 2: Open ID Connect

Work ow assumes a temporary,

via secrets
provider-managed role
fl
fl
 A Complete, Realistic Example
Applying What You Learned

Build Two Complete, Realistic Example Work ows

Work ow 1: Complete Deployment Work ow A - Z

Work ow 2: Manage Repository Issues

fl
fl
 An Example Workflow
1
Demo Website
Get code (from repository)

Goal 2
Deploy (“publish”) the website Install dependencies

Trigger 3
Whenever a new commit is pushed Build website
to the “main” branch
4
Run automated tests

5
Deploy website