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.
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
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
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
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
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' }}
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
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
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
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)
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