1. What Is “GitHub Actions”?
A Work
fl
ow Automation Service by GitHub
Code Deployment
(CI / CD)
Code & Repository Management
Automate all kinds of repository-
related processes & actions
Automate code testing, building &
deployment
Automate code reviews, issue
management etc.
3. What’s CI / CD?
Continuous Integration Continuous Delivery
Methods for
automating app
development &
deployment
Code changes are
automatically built, tested &
merged with existing code
After integration, new app or
package versions are
published automatically
4. A Typical CI / CD Workflow
Code was changed
(e.g, new feature added)
New Git Commit
Pushed to GitHub
Repository
App is built
App is tested
(e.g., unit tests)
App is published
(e.g., on AWS EC2)
CI / CD Work
fl
ow
Can be con
fi
gured & executed
via GitHub Actions
5. GitHub Actions Alternatives
GitHub Actions
For CI / CD
Alternatives
Jenkins GitLab CI/CD Azure Pipelines AWS CodePipeline
and many more …
7. What Is GitHub?
A cloud Git repository & services
provider
Store & manage Git repositories
8. What Is Git?
A (free) version control system
A tool for managing source code changes
Save code snapshots
(“commits”)
Work with alternative code
versions (“branches”)
Move between branches &
commits
With Git, you can easily roll back to older code snapshots or
develop new features without breaking production code.
9. What Is GitHub?
A cloud Git repository & services
provider
Store & manage Git repositories
Cloud Git repository storage
(“push” & “pull”)
Code management &
collaborative development
Automation & CI / CD
Via “Issues”, “Projects”, “Pull
Requests” & more
Via GitHub Actions, GitHub
Apps & more
Backup, work across
machines & work in teams
Public & private, team
management & more
10. About This Course
Learn GitHub Actions From The Ground Up
Video-based
Explanations
Practice & Experiment Learn & Grow Together
Watch the videos—at your pace
Recommendation: Watch all
videos in the provided order
Repeat videos as needed
Pause videos and practice on
your own
Build up on course examples &
feel free to experiment
Build your own demo projects &
work
fl
ow examples
Help each other in the course
Q&A section
Dive into our (free!) community
11. Git & GitHub Crash Course
The Very Basics
Working with Git: Setup & Key Commands
Working with GitHub: Creating & Using Repositories
Using Git with GitHub
12. What Is Git?
A (free) version control system
A tool for managing source code changes
Save code snapshots
(“commits”)
Work with alternative code
versions (“branches”)
Move between branches &
commits
With Git, you can easily roll back to older code snapshots or
develop new features without breaking production code.
13. Git Repositories
Git features can be used in projects
with Git repositories
A repository is a folder used by Git to
track all changes of a given project
Create Git repositories via git init
Only required once per
folder / project
Git commands require a
repository in a project
Some projects initialize Git for you e.g., React projects
14. Working with Commits (Code Snapshots)
Create Commits Move between Commits
git add <file(s)>
Stage changes for next
commit
git commit
Create a commit that
includes all staged changes
git checkout <id>
Temporarily move to
another commit
C1 C2 C3 C4 C5 C6
C6
HEAD
15. Working with Commits (Code Snapshots)
Create Commits Move between Commits
git add <file(s)>
Stage changes for next
commit
git commit
Create a commit that
includes all staged changes
git checkout <id>
Temporarily move to
another commit
C1 C2 C3 C4 C5 C6
HEAD
16. 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
fi
les
in a Git repository
17. Working with Commits (Code Snapshots)
Create Commits Move between Commits
git add <file(s)>
Stage changes for next
commit
git commit
Create a commit that
includes all staged changes
git checkout <id>
Temporarily move to
another commit
C1 C2 C3 C4 C5 C6
HEAD
18. Working with Commits (Code Snapshots)
Create Commits Move between Commits Undo Commits
git add <file(s)>
Stage changes for next
commit
git commit
Create a commit that
includes all staged changes
git checkout <id>
Temporarily move to
another commit
git revert <id>
Revert changes of commit
by creating a new commit
C1 C2 C3 C4 C5 C6
HEAD
19. Working with Commits (Code Snapshots)
Create Commits Move between Commits Undo Commits
git add <file(s)>
Stage changes for next
commit
git commit
Create a commit that
includes all staged changes
git checkout <id>
Temporarily move to
another commit
git revert <id>
Revert changes of commit
by creating a new commit
C1 C2 C3 C4 C5 C7
HEAD
C6
20. Working with Commits (Code Snapshots)
Create Commits Move between Commits Undo Commits
git add <file(s)>
Stage changes for next
commit
git commit
Create a commit that
includes all staged changes
git checkout <id>
Temporarily move to
another commit
git revert <id>
Revert changes of commit
by creating a new commit
C1 C2 C3 C4 C5 C6
HEAD
git reset --hard <id>
Undo changes by deleting all
commits since <id>
21. Working with Commits (Code Snapshots)
Create Commits Move between Commits Undo Commits
git add <file(s)>
Stage changes for next
commit
git commit
Create a commit that
includes all staged changes
git checkout <id>
Temporarily move to
another commit
git revert <id>
Revert changes of commit
by creating a new commit
C1 C2 C3
git reset --hard <id>
Undo changes by deleting all
commits since <id>
C4
HEAD
22. 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
24. What Is GitHub?
A cloud Git repository & services
provider
Store & manage Git repositories
Cloud Git repository storage
(“push” & “pull”)
Code management &
collaborative development
Automation & CI / CD
Via “Issues”, “Projects”, “Pull
Requests” & more
Via GitHub Actions, GitHub
Apps & more
Backup, work across
machines & work in teams
Public & private, team
management & more
25. GitHub Repositories
Cloud storage for your Git repositories
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
Backup, cross-device
usage, collaboration
26. Forking & Pull Requests
Repository Forking Pull Requests
Creates a standalone copy of
a repository
Can be used to work on code
without a
ff
ecting the original
repository
Requests merging code
changes into a branch
Can be based on a forked
repository or another branch
from the same repository
Pull requests allow for code
reviews before merging
changes
27. GitHub Actions: Fundamentals
Key Building Blocks & Usage
Understanding the Key Elements
Working with Work fl
ows, Jobs & Steps
Building an Example Work
fl
ow
28. Key Elements
Work
fl
ows Jobs Steps
Attached to a GitHub
repository
Contain one or more Jobs
Triggered upon Events
De
fi
ne a Runner (execution
environment)
Contain one or more Steps
Run in parallel (default) or
sequential
Execute a shell script or an
Action
Can use custom or third-
party actions
Steps are executed in order
Can be conditional Can be conditional
30. Events (Workflow Triggers)
Repository-related Other
push
Pushing a commit
pull_request
Pull request action
(opened, closed, …)
create
A branch or tag was
created
fork
Repository was
forked
issues
An issue was opened,
deleted, …
issue_comment
Issue or pull request
comment action
watch
Repository was
starred
discussion
Discussion action
(created, deleted, …)
Many More!
work
fl
ow_dispatch
Manually trigger
work
fl
ow
repository_dispatch
REST API request
triggers work
fl
ow
schedule
Work
fl
ow is scheduled
work
fl
ow_call
Can be called by other
work
fl
ows
31. What Are Actions?
A (custom) application that
performs a (typically complex)
frequently repeated task
Action
Command
(“run”)
A (typically simple) shell command
that’s de
fi
ned by you
You can build your own Actions but
you can also use o
ffi
cial or
community Actions
33. Module Summary
Core Components
Work
fl
ows: De
fi
ne Events + Jobs
Jobs: De
fi
ne Runner + Steps
Steps: Do the actual work
Events / Triggers
Broad variety of events
(repository-related & other)
Work
fl
ows have at least one (but
possible more) event(s)
Work
fl
ow Execution
Work
fl
ows are executed when
their events are triggered
GitHub provides detailed insights
into job execution (+ logs)
De
fi
ning Work
fl
ows
.github/work
fl
ows/<
fi
le>.yml
(on GitHub or locally)
GitHub Actions syntax must be
followed
Runners
Servers (machines) that execute
the jobs
Pre-de
fi
ned Runners (with
di
ff
erent OS) exist
You can also create custom
Runners
Actions
You can run shell commands
But you can also use pre-de
fi
ned
Actions (o
ffi
cial, community or
custom)
34. Exercise Time!
Create 2 Work
fl
ows
Use the Attached
Project
Lint, Test & Deploy on
“push”
Output Event Details on
“issues”
Run the “lint”, “test” &
“build” scripts
Use one or three jobs
(running after each other)
Output event details in the
shell via “echo”
Use the “issues” event &
“github” context
35. Events: A Closer Look
Diving Deeper Into Workflow Triggers
Controlling Work fl
ow Execution with Event Filters
Detailed Control with Activity Types
Examples!
36. Available Events
Repository-related Other
push
Pushing a commit
pull_request
Pull request action
(opened, closed, …)
create
A branch or tag was
created
fork
Repository was
forked
issues
An issue was opened,
deleted, …
issue_comment
Issue or pull request
comment action
watch
Repository was
starred
discussion
Discussion action
(created, deleted, …)
Many More!
work
fl
ow_dispatch
Manually trigger
work
fl
ow
repository_dispatch
REST API request
triggers work
fl
ow
schedule
Work
fl
ow is scheduled
work
fl
ow_call
Can be called by other
work
fl
ows
37. Event Activity Types & Filters
Event e.g., push, pull_request
Activity Types
Some events have
More detailed control over when a
work
fl
ow will be triggered
pull_request Event
opened
closed
edited
…
Filters
More detailed control over when a
work
fl
ow will be triggered
push Event
Filter based
on target
branch
38. A Note About Fork Pull Request Workflows
By default, Pull Requests based on
Forks do NOT trigger a work
fl
ow
Reason: Everyone can fork &
open pull requests
Malicious work
fl
ow runs &
excess cost could be caused
First-time contributors must be
approved manually
39. Cancelling & Skipping Workflow Runs
Skipping
Cancelling
By default, Work
fl
ows get
cancelled if Jobs fail
By default, a Job fails if at
least one Step fails
You can also cancel
work
fl
ows manually
By default, all matching
events start a work
fl
ow
Exceptions for “push” &
“pull_request”
Skip with proper commit
message
40. Module Summary
Available Events
There are many supported events
Most are repository-related (e.g.,
push, pull_request)
But some are more general (e.g.,
schedule)
Activity Types
The exact type of event that
should trigger a work
fl
ow
Examples: Opening or editing a
pull request should trigger the wf
Event Filters
For push & pull_request: Add
fi
lters to avoid some executions
Filter based on target branch and
/ or a
ff
ected
fi
le paths
Pull Requests & Forks
Initial approval needed for pull
requests from forked repositories
Avoids spam from untrusted
contributors
Cancelling & Skipping
Work
fl
ows get cancelled
automatically when jobs fail
You can manually cancel
work
fl
ows
You can skip via [skip ci] etc. in
commit message
41. Exercise Time!
Test & Deploy For “main”
Pushes & Manual Trigger
1
Run Tests Upon Pull
Requests
2
Goal: Run Work
fl
ow if a
commit is pushed to the
“main” branch
Ignore push events for other
branches
Variation
Also run for “dev” branch and
DON’T run if work
fl
ow
fi
les
were edited
Goal: Run Work
fl
ow if a
collaborator pull_request is
opened
Only run for pull_requests
targeting the “main” branch
Variation
Also run for “dev” branch
42. Job Data & Outputs
It’s All About Data!
Working with Artifacts
Working with Job Outputs
Caching Dependencies
43. Understanding Job Artifacts
Job Example: Build app
Output Asset(s)
Example: App binary,
website
fi
les etc.
Download & Use
Manually
Download & Use in
other Jobs
Via GitHub UI or REST
API
Via Action
44. Understanding Job Outputs
Artifacts Job Outputs
Output
fi
les & folders Simple values
Typically used for
sharing log
fi
les, app
binaries etc.
Typically used for re-
using a value in di
ff
erent
jobs
Example: Name of a
fi
le
generated in a previous
build step
45. Caching Dependencies
Get Code
Install Dependencies
Build Project
Get Code
Install Dependencies
Test App
Often repeated
Dependencies
don’t change
frequently
46. Module Summary
Artifacts
Jobs often product assets that
should be shared or analyzed
Examples: Deployable website
fi
les, logs, binaries etc.
These assets are referred to as
“Artifacts” (or “Job Artifacts”)
Outputs
Besides Artifacts, Steps can
product and share simple values
These outputs are shared
via ::set-output
Caching
Caching can help speed up
repeated, slow Steps
Typical use-case: Caching
dependencies
GitHub Actions provides Actions
for uploading & downloading
Jobs can pick up & share Step
outputs via the steps context
Other Jobs can use Job outputs
via the needs context
But any
fi
les & folder can be
cached
The cache Action automatically
stores & updates cache values
(based on the cache key)
Important: Don’t use caching for
artifacts!
47. Environment Variables & Secrets
Hardcoding Is Not (Often) The Solution
Understanding & Using Environment Variables
Using Secrets
Utilizing Job Environments
49. Environment Variables vs Secrets
Some environment variable values
should never be exposed
Example: Database access password
Use Secrets
Together with
environment variables
50. GitHub Repository Environments
GitHub Environments Attached to Repositories
Work
fl
ow Jobs can target
Environments
Di
ff
erent Con
fi
gurations
Di
ff
erent Secrets for di
ff
erent
environments (e.g., di
ff
erent
database passwords)
Special protection rules
e.g., only events related to
certain branches can use an
environment
51. Module Summary
Environment Variables
Dynamic values used in code
(e.g., database name)
May di
ff
er from work
fl
ow to
work
fl
ow
Can be de
fi
ned on Work
fl
ow-,
Job- or Step-level
Secrets
Some dynamic values should not
be exposed anywhere
Examples: Database credentials,
API keys etc.
GitHub Actions Environments
Jobs can reference di
ff
erent
GitHub Actions Environments
Environments allow you to set up
extra protection rules
Can be used in code and in the
GitHub Actions Work
fl
ow
Secrets can be stored on
Repository-level or via
Environments
Secrets can be referenced via the
secrets context object
You can also store Secrets on
Environment-level
Accessible via interpolation and
the env context object
52. Controlling Execution Flow
Beyond Step-By-Step Flows
Running Jobs & Steps Conditionally
Running Jobs with a Matrix
Re-Using Work
fl
ows
56. Conditional Jobs & Steps
Jobs Steps
Conditional execution via
if
fi
eld
Conditional execution via
if
fi
eld
Ignore errors via
continue-on-error
fi
eld
Evaluate conditions via Expressions
57. Special Conditional Functions
always() cancelled()
failure() success()
Returns true when any
previous Step or Job failed
Returns true when none
of the previous steps have
failed
Causes the step to always
execute, even when
cancelled
Returns true if the
work
fl
ow has been
cancelled
59. Module Summary
Conditional Jobs & Steps
Control Step or Job execution
with if & dynamic expressions
Change default behavior with
failure(), success(),
cancelled() or always()
Use continue-on-error to
ignore Step failure
Matrix Jobs
Run multiple Job con
fi
gurations in
parallel
Add or remove individual
combinations
Reusable Work
fl
ows
Work
fl
ows can be reused via the
workflow_call event
Reuse any logic (as many Jobs &
Steps as needed)
Control whether a single failing
Job should cancel all other Matrix
Jobs via continue-on-error
Work with inputs, outputs and
secrets as required
61. What Are Containers?
Docker Container
Packages that contain code + its
execution environment
Advantage: Reproducible
execution environment & results
62. Containers & GitHub Actions
Docker Container
Packages that contain code + its
execution environment
Advantage: Reproducible
execution environment & results
GitHub Actions Runners
still runs on
Your containerized Job is hosted
by the Runner
Steps execute inside the
container
You can also create Services:
Utility containers used by your
Steps (Example: Testing
Database)
63. Why Use Containers?
Just the Runner
Container
Full control over environment
& installed software
Choose from list of pre-
de
fi
ned environments (incl.
installed software)
64. Using Service Containers (“Services”)
Job
Example: Runs tests
Problem: Tests should not
manipulate production
database
Solution: Use a testing
database
Service Container
Example: Hosts a testing
database
Runs inside a container
(hosted by the Runner)
Job steps can communicate
with service containers (and
the services exposed by
them)
65. Module Summary
Containers
Packages of code + execution
environment
Great for creating re-usable
execution packages & ensuring
consistency
Example: Same environment for
testing + production
Containers for Jobs
You can run Jobs in pre-de
fi
ned
environments
Build your own container images
or use public images
Service Containers
Extra services can be used by
Steps in Jobs
Example: Locally running, isolated
testing database
Great for Jobs that need extra
tools or lots of customization
Based on custom images or
public / community images
66. Building Custom Actions
Beyond Shell Commands & The Marketplace
What & Why?
Di
ff
erent Types of Custom Actions
Building & Using Custom Actions
67. Why Custom Actions?
Simplify Work
fl
ow Steps
No Existing (Community)
Action
Instead of writing multiple
(possibly very complex) Step
de
fi
nitions, you can build and
use a single custom Action
Multiple Steps can be grouped
into a single custom Action
Existing, public Actions might
not solve the speci
fi
c problem
you have in your Work
fl
ow
Custom Actions can contain
any logic you need to solve
your speci
fi
c Work
fl
ow
problems
68. Different Types of Custom Actions
JavaScript Actions Docker Actions Composite Actions
Execute a JavaScript fi
le
Use JavaScript (NodeJS) +
any packages of your choice
Pretty straightforward (if you
know JavaScript)
Create a Docker
fi
le with your
required con
fi
guration
Perform any task(s) of your
choice with any language
Lots of
fl
exibility but requires
Docker knowledge
Combine multiple Work
fl
ow
Steps in one single Action
Combine run (commands)
and uses (Actions)
Allows for reusing shared
Steps (without extra skills)
{}
69. Module Summary
What & Why?
Simplify Work
fl
ows & avoid
repeated Steps
Implement logic that solves a
problem not solved by any
publicly available Action
Create & share Actions with the
Community
Composite Actions
Create custom Actions by
combining multiple Steps
Composite Actions are like
“Work
fl
ow Excerpts”
JavaScript & Docker Actions
Write Action logic in JavaScript
(NodeJS) with @actions/toolkit
Alternatively: Create your own
Action environment with Docker
Use Actions (via uses) and
Commands (via run) as needed
Either way: Use inputs, set outputs
and perform any logic
70. Permissions & Security
Keep Things Secure
Securing Your Work
fl
ows
Working with GitHub Tokens & Permissions
Third-Party Permissions
71. Security Concerns
Script Injection
Malicious Third-Party
Actions
Permission Issues
A value, set outside a
Work
fl
ow, is used in a
Work
fl
ow
Example: Issue title used in a
Work
fl
ow shell command
Work
fl
ow / command
behavior could be changed
Actions can perform any
logic, including potentially
malicious logic
Example: A third-party Action
that reads and exports your
secrets
Only use trusted Actions and
inspect code of unknown /
untrusted authors
Consider avoiding overly
permissive permissions
Example: Only allow checking
out code (“read-only”)
GitHub Actions supports
fi
ne-
grained permissions control
72. Using Actions Securely
Only use your own Actions Highest Level of Security
Only use Actions by veri
fi
ed
creators
Use all public Actions Lowest Level of Security
You should
analyze the
Action code
fi
rst!
Still not a 100%
guarantee!
Considerable
amount of
e
ff
ort
73. GitHub Permissions & GITHUB_TOKEN
Work
fl
ows run Job on Runners
Runners: Isolated, virtual machines
Why do they have access to your
GitHub repository?
e.g., for checking out the
code or inspecting issues
GitHub creates an authentication
token (GITHUB_TOKEN)
Valid for the duration of a
Work
fl
ow Job
74. Third-Party Permissions
Especially for deployment tasks, GitHub
Work
fl
ows regularly communicate with third-
party cloud / hosting providers
Credentials / Authentication required
Option 1: API or Access Keys
via secrets
Option 2: Open ID Connect
Work
fl
ow assumes a temporary,
provider-managed role
75. A Complete, Realistic Example
Applying What You Learned
Build Two Complete, Realistic Example Work ows
Work
fl
ow 1: Complete Deployment Work ow A - Z
Work
fl
ow 2: Manage Repository Issues
76. An Example Workflow
Demo Website
Goal
Deploy (“publish”) the website
Get code (from repository)
1
Install dependencies
2
Build website
3
Run automated tests
4
Deploy website
5
Trigger
Whenever a new commit is pushed
to the “main” branch
