It's been said that automating oneself out of a job is one of the best qualities of a software engineer. When it comes to building and releasing software that statement becomes more relevant than ever. GitHub is a popular choice for hosting code and since a few years ago offers a native CI/CD solution: GitHub Actions. They are a powerful tool that's worth adding to your development toolbox but getting started might be a bit daunting. In this session we'll cover the basics of working with GitHub Actions workflows and their structure, moving into more advanced topics such as inputs/outputs, job dependencies, job matrices, reusable workflows, composite actions, and secrets.

1. Ixchel Ruiz
Lights, Camera, GitHub Actions!
@ Utrecht JUG

2. Ixchel Ruiz
Senior Software Developer, DA @JFrog
@ixchelruiz@mastodon.social
www.linkedin.com/in/ixchelruiz

4. Github Actions

5. Github: Octoverse 2022
94M developers are on GitHub
Languages on GitHub → 1st JavaScript, 2nd Python, 3rd Java

6. Github Actions

7. Github Actions
Automated testing
Automatically responding to new issues, mentions
Triggering code reviews
Handling pull requests
Branch management

8. Github Actions : What?
Actions are the mechanism used to provide workflow
automation within the GitHub environment.

9. Github Actions : What?
Defined in YAML and stay within GitHub repositories
Executed on "runners," either hosted by GitHub or self-hosted
Contributed actions can be found in the GitHub Marketplace

10. Events
Work
fl
ows
Jobs
Actions
Trigger
Contain
Use

11. Github Actions
Name: name of the work
fl
ow
On: event or list that will trigger the work
fl
ow
Jobs: list of jobs to be executed
Runs-on: runner to use
Steps: list of steps (within a job executed on the same
runner)
Uses: prede
fi
ned action to be retrieved
Run: execute a command on the runner

14. inputs
github.event.inputs

16. Inputs

19. Workflow triggers : Events

20. Events
Events that occur in the work
fl
ow's repository
Events that occur outside of GitHub and trigger
a repository_dispatch event on GitHub
Scheduled times
Manual

21. Events
branch_protection_rule
check_run
check_suite
create
delete
deployment
deployment_status
discussion
discussion_comment
fork
gollum
issue_comment
issues
label
milestone
page_build
project
project_card
project_column
public
pull_request
pull_request_comment(use issue_comment)
pull_request_review
pull_request_review_comment
pull_request_target push
registry_package
release
repository_dispatch
schedule
status
watch
work
fl
ow_call
work
fl
ow_dispatch
work
fl
ow_run

22. Events
branch_protection_rule
check_run
check_suite
create
delete
deployment
deployment_status
discussion
discussion_comment
fork
gollum
issue_comment
issues
label
milestone
page_build
project
project_card
project_column
public
pull_request
pull_request_comment(use issue_comment)
pull_request_review
pull_request_review_comment
pull_request_target push
registry_package
release
repository_dispatch
schedule
status
watch
work
fl
ow_call
work
fl
ow_dispatch
work
fl
ow_run

23. Events
on:
gollum
Work
fl
ows can be executed when a GitHub webhook is called
This event would
fi
re when someone updates or
fi
rst creates a Wiki
page

24. Scheduling

25. Scheduling
on:
schedule:
# * is a special character in YAML so you have to quote this string
- cron: '30 5,17 * * *'
Every day at 5:30 and 17:30 UTC
Cron schedules are based on
fi
ve values:
Minute (0 - 59)
Hour (0 - 23)
Day of the month (1 - 31)
Month (1 - 12)
Day of the week (0 - 6)
on:
schedule:
- cron: '30 5 * * 1,3'
- cron: '30 5 * * 2,4'
jobs:
test_schedule:
runs-on: ubuntu-latest
steps:
- name: Not on Monday or Wednesday
if: github.event.schedule != '30 5 * * 1,3'
run: echo "This step will be skipped on Monday and Wednesday"
- name: Every time
run: echo "This step will always run"
cron: '30 5,17 * * *'
cron: '30 5 * * 1,3’
cron: '30 5 * * 2,4’
if: github.event.schedule != '30 5 * * 1,3'

26. Conditionals
jobs:
production-deploy:
if: github.repository == 'octo-org/octo-
repo-prod'
runs-on: ubuntu-latest
steps:
- name: My
fi
rst step
if: ${{ github.event_name == 'pull_request'
&& github.event.action == 'unassigned' }}
run: echo “This event is a pull request that
had an assignee removed”
if: github.repository == ‘octo-org/octo-repo-prod'
if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}

27. Filters

28. Filters
on:
pull_request:
types:
- opened
branches:
- 'releases/**'
paths:
- '**.js'
will only run when all
fi
lters are satis
fi
ed.
will only run when a pull request that includes a change to a JavaScript (.js)
fi
le is opened on a branch whose name starts with releases/

29. Filters : Refs
on:
pull_request:
# patterns refs/heads
branches-ignore:
- 'mona/octocat'
- ‘releases/**-alpha’
on:
pull_request:
branches:
- 'releases/**'
- '!releases/**-alpha'
branches-ignore branches: !

30. Filters: Tags
on:
push:
# patterns refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
# patterns refs/tags
tags:
- v2
- v1.*
on:
push:
#patterns refs/heads
branches-ignore:
- 'mona/octocat'
- 'releases/**-alpha'
# patterns refs/tags
tags-ignore:
- v2
- v1.*
will only run when all
fi
lters are satis
fi
ed.
tags-ignore
tags

31. Jobs

32. Jobs
Work
fl
ows contain one or more jobs
A job is a set of steps that will be run in order on a runner.
Steps within a job execute on the same runner and share the same
fi
lesystem
The logs produced by jobs are searchable

33. Jobs : Run
Jobs run in parallel by default.
sequentially → de
fi
ne dependencies ( needs )
needs

35. Defining prerequisite jobs

36. Prerequisite jobs: Expressions
jobs:
job1:
job2:
needs: job1
job3:
needs: [job1, job2]
*Requiring successful dependent jobs
jobs:
job1:
job2:
needs: job1
job3:
if: ${{ always() }}
needs: [job1, job2]
*Not requiring successful dependent jobs
if: ${{ always() }}
needs

37. Permissions

38. Permissions
actions: read | write | none
checks: read | write | none
contents: read | write | none
deployments: read | write | none
id-token: read | write | none
issues: read | write | none
discussions: read | write | none
packages: read | write | none
pages: read | write | none
pull-requests: read | write | none
repository-projects: read | write | none
security-events: read | write | none
statuses: read | write | none

40. permissions

41. permissions

42. Concurrency

43. Concurrency
concurrency:
group: ${{ github.ref }}
cancel-in-progress: true
concurrency:
group: ${{ github.head_ref || github.run_id }}
cancel-in-progress: true
concurrency:
group: ${{ github.work
fl
ow }}-${{ github.ref }}
cancel-in-progress: true
Using concurrency to cancel any in-progress job or run
Only cancel in-progress jobs or runs for the current work
fl
ow
Using a fallback value
concurrency:
group: '${{ github.work
fl
ow }} @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
cancel-in-progress: true

44. Reusable Workflows

45. Reusable Workflows
A work
fl
ow that uses another work
fl
ow is referred to as a "caller"
work
fl
ow.
The reusable work
fl
ow is a "called" work
fl
ow.
One "caller" work
fl
ow can use multiple "called" work
fl
ows.
Each "called" work
fl
ow is referenced in a single line.

46. Reusable Workflows
When a reusable work
fl
ow is triggered by a caller work
fl
ow, the github
context is always associated with the caller work
fl
ow.
The called work
fl
ow is automatically granted access to
github.token and secrets.GITHUB_TOKEN.

47. Reusable Workflows : outputs
name: Reusable work
fl
ow
on:
work
fl
ow_call:
# Map the work
fl
ow outputs to job outputs
outputs:
fi
rstword:
description: "The
fi
rst output string"
value: ${{ jobs.example_job.outputs.output1 }}
secondword:
description: "The second output string"
value: ${{ jobs.example_job.outputs.output2 }}
jobs:
example_job:
name: Generate output
runs-on: ubuntu-latest
# Map the job outputs to step outputs
outputs:
output1: ${{ steps.step1.outputs.
fi
rstword }}
output2: ${{ steps.step2.outputs.secondword }}
steps:
- id: step1
run: echo "
fi
rstword=hello" >> $GITHUB_OUTPUT
- id: step2
run: echo "secondword=world" >> $GITHUB_OUTPUT
name: Call a reusable work
fl
ow and use its outputs
on:
work
fl
ow_dispatch:
jobs:
job1:
uses: octo-org/example-repo/.github/work
fl
ows/called-work
fl
ow.yml@v1
job2:
runs-on: ubuntu-latest
needs: job1
steps:
- run: echo ${{ needs.job1.outputs.
fi
rstword }} ${{ needs.job1.outputs.secondword }}
called ( called-work
fl
ow.yml ) caller work
fl
ow

48. Reusable Workflows : secrets
jobs:
work
fl
owA-calls-work
fl
owB:
uses: octo-org/example-
repo/.github/work
fl
ows/B.yml@main
secrets: inherit
# pass all secrets
jobs:
work
fl
owB-calls-work
fl
owC:
uses: different-org/example-
repo/.github/work
fl
ows/C.yml@main
secrets:
envPAT: ${{ secrets.envPAT }}
# pass just this secret
B will inherit ALL secrets C will inherit envPAT secret

49. Reusable Workflows : Limitation
• Connect up to 4 levels of work
fl
ows
• Call a maximum of 20 reusable work
fl
ows
• Env variables ( env context @ caller work
fl
ow) not propagated to
called
• Env variables ( env context @ called work
fl
ow) not accessible to
caller Use outputs
• Reuse variables multiple work
fl
ows —> organization, repository, or environment levels (vars context)
• Reusable work
fl
ows (within a job and not step)

50. Secrets

51. Secrets
Secrets use Libsodium sealed boxes, so that they are encrypted
before reaching GitHub.
Never use structured data as a secret. Github attempts to redact any secrets that appear in run logs.
With the exception of GITHUB_TOKEN, secrets are not passed to the
runner when a work
fl
ow is triggered from a forked repository.
Secrets cannot be directly referenced in if: conditionals.
Register all secrets used within work
fl
ows

52. Demo

53. THANK YOU!