A collection of GitHub Actions workflows where I demonstrate various capabilities and features.
They serve as a quickstart and reference for my future self. Each are described below.
A basic workflow to do all the essentials.
- Runs when changes are pushed
- Runs on a schedule
- Can be run manually from the GitHub UI
- Uses actions/checkout
- Uses actions/setup-python with pip cache
- Installs
requirements.txt
and runs a simple test - Includes
dependabot.yml
to automatically check for package updates
Getting the branch name is a common CI operation. Surprisingly, there's no pre-defined way to get it in GitHub Actions.
This demo shows the simplest way without using 3rd party actions or invoking various tools.
It works in most cases, but there are some quirks.
For example, if your commit is tagged this method will return the tag instead of the branch name. See SO link in the references for details.
You may also get an unexpected result depending on the event that triggered the workflow. This demo is set to trigger on pull_request
and on push
to illustrate this behavior.
- Shows various
github
context properties that may or may not contain the branch name - Sets branch name to the top level
env
so it can be accessed by the entire workflow
Contexts are a way to access information about workflow runs, variables, runner environments, jobs, and steps.
This can be helpful for debugging workflow errors or bugs.
Warning: Be careful when printing the entire context as it may contain sensitive information.
- Shows various contexts
Environment variables and their scopes work as you'd expect in GitHub Actions.
They're also fairly self-contained, so any changes you make are isolated to the job you're in.
One quirk that can cause confusion is the fact that environment variables defined within a step aren't accessible until the next step.
- Read env vars
- Write env vars
- Pass env vars
Read, write, and modify PATH like any other environment variable. It has the same quirks.
- Modify PATH env var
GitHub provides an action that lets you easily write javascript directly in your workflow.
The action includes an object with the current workflow context and references to several other useful packages. It's also a pre-authenticated octokit/rest.js client.
If you develop on macOS you're probably familiar with homebrew.
Did you know it's also available on Linux?
This demo shows how you can leverage its power and convenience to install applications on GitHub Actions runners.
- GitHub Docs: GitHub Actions
- GitHub Docs: Accessing contextual information about workflow runs
- GitHub Docs: Adding a system path
- GitHub Docs: Configuration options for the dependabot.yml file
- GitHub Docs: Events that trigger workflows
- GitHub Docs: jobs.<job_id>.outputs
- GitHub Docs: Setting an environment variable
- GitHub Docs: Workflow syntax for GitHub Actions
- octokit/rest.js API documentation
- Stack Overflow: How to get a branch name on GitHub action when push on a tag?
- Stack Overflow: How to get the current branch within Github Actions?