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
- 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 of a workflow file
- 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
- 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
-
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.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent