Small examples of interesting GitHub actions combinations.
Most workflows where intentionally left with workflow_dispatch so they don't
run by accident on every commit. Not as if it was a big issue, since they do
mostly nothing by design.
But you can also run them using the act command line tool, which emulates the GitHub actions environment in a quite near the real thing way.
So, the three big ways to run a workflow:
- Visit the actions page and run them by hand
- Use the GitHub CLI:
gh workflow run .github/workflow/00-hello-world.yml - Use act:
act -W .github/workflows/00-hello-world.yml
GitHub Actions is what happens when yaml and bash decide to have a child.
The workflow files are used to common integration routines: run tests, check the quality of code, perform any chore that can be automatized, scripted.
Each workflow file must define:
- name (unique across all workflows)
- on (event)
- jobs (actual work)
What could possibly trigger an workflow?
- You hit a button
- A git push or something
- Another workflow
More possibilities here.
- Give cool names to your jobs, not just build
- One workflow can house several jobs
- Jobs will run in parallel unless you do something about it
- make jobs
needsother jobs - run jobs
ifsome condition is true
- make jobs
More details here.
00 - smallest possible
- The 101 of CI
- Echoes 'hello word from some branch'
02 - have two jobs
- Remember, runs in parallel!
- Pretty much like two distinct workflows, but sharing rent on the same workflow file. Useful in more complex builds.
- Make sure the second needs the first
- This is why workflow_call exists
- Don't misread as workflow_dispatch, it's another thing
- Quite similar to what we do when consuming actions from marketplace
05 - jobs inputs
- Both
workflow_callandworkflow_dispatchcan receive inputs - Use inputs inside the steps inside jobs
06 - jobs outputs
- You can define outputs values so other jobs can check on
- For dynamic outputs check the
$GITHUB_OUTPUTvariable usage
- The repository itself can contribute with custom variables
- Use GitHub CLI to list, set or remove repository variables
- If using act, create a
.varsfile to define variables - With
actthere is also a.envfile but we talk about it later
# ~/github/gh-actions-playground/.vars
X="some value from vars"
08 - secrets
- Very useful to interact with the world outside the repo
- Define secrets via web console settings
- Or use GitHub CLI to create them, pretty handy!
- With act, just put it inside a
.secretsfile! - Note: secret values are not echoed on logs
# ~/github/gh-actions-playground/.secrets
X=10
MY_SECRET="not telling you!"[sombriks@thanatos gh-actions-playground](main)$ gh secret set X
? Paste your secret **
✓ Set Actions secret X for sombriks/gh-actions-playground09 - steps
- Simplest step is a
runcommand - Complex ones
usesexternal actions from marketplace - Give proper
namesfor your steps
More details of what is possible here
- Define a reusable workflow with an output section
- Define a workflow with a job consuming the reusable one
- Useful to modify something in the repo as part of the workflow
- Does not trigger other workflows
- Can manipulate several branches, see checkout action for details.
- Useful to report some important result as part of the workflow
- Event needed is a pull request
The key difference is a reusable workflow will eat an entire job, while a reusable action only a step.
Actions can't access env or secrets directly, you must pass inputs.
You can define custom actions locally to the repo or use 3rd party ones.
-
This is why GitHub Actions it's better than other CI tools from other vendors
-
Rich ecosystem
There's much, much more!
- Run tests
- Publish packages or images
- For GitOps, update desired state on IaC manifests files
This playground is intended to be simple, educational.
It's up to you combine the techniques sampled here to build real things.