This post covers the purpose of and basic terms around GH Actions, as well as links to workflows and actions for you to use.
If you know about it already and want to build a test and deploy pipeline right away, skip ahead to my other blog post:
You'll see some code snippets there and how to use them in a simple project.
Otherwise keep reading below for more concepts and less code.
GH Actions is a free service which can run on a repo if configured. It is similar to CircleCI, if you've heard of that.
GH Actions lets us:
- Run shell commands against our repo code (usually Bash on Ubuntu)
- Use GH's cloud infrastructure
- Trigger on an event, like a commit, a PR or on a schedule, even on a manual button press now.
Read about GitHub Actions as a feature on the GitHub site.
GH Actions takes out the pain of manually running commands on your machine and moves it to the cloud to automated runners.
You don't have to touch your terminal but you'll get a log of steps which is centralized and public - nice to share across your team or open-source contributors. The job runs each pass and fail status and the corresponding commit - so you can track down a bug by seeing the first time your job switched from passing to failing state.
You might use GH Actions to build and deploy your package or website, but only if all the safety checks you've setup are met. This builds confidence in getting a quality product delivered.
Your actions config is a "workflow" of triggers and steps.
These steps which can be a mixture of:
- shell commands (like
pip install ...or
npm run build)
- external actions (covered below)
A workflow file is stored here as YAML file:
A workflow is the config file.
The job is the what actually executes.
You can see a history of runs for a single job.
You can see runs for the "Node CI" job here in my Node.js quickstart repo.
You can find an action available in the Actions "marketplace" but really it is a repo that is published by the community and accepted by GH if it meets standards.
An action is a packaged, reusable flow which you can use like a library or module. Use it to do more complex tasks in your workflow without writing the code yourself.
Note that you don't have to use an action. You can build and test a Node.js app for example using just plain commands as steps.
But if you want more advanced functionality, an action is great:
- Installing and building against using multiple version of your runtime e.g. Node 10, 12 and 14. Or Python 3.8 and 3.9.
- Posting to Slack or Twitter
- Building a Jekyll site or Node web app to a
gh-pagesbranch to serve on GH Pages. See my vue-quickstart workflow.
There are plenty of actions in the GitHub Actions marketplace. A lot of them do similar things so you'll have to compare them.
If you want to make your own action as a standalone for you and others to use, see this guide:
- Creating Actions on GH's docs
When you create a new workflow under Actions tab of your repo, you'll also get a choice of start workflows which typically use actions.
See the actions/starter-workflows repo.
I have collected workflow files from all over GH repos and the GH docs and writing my own. I use this central collection regularly when I need to see what pattern I or others typically follow.
Feel free to copy and paste part or all of a workflow you like to your project. See the Workflows in my Code Cookbook.
That's my quickstart for GH Actions. Let me know if you need more info.
For interest, check the #ActionsHackathon tag on dev.to.
Cover image by @jakobowens1 on Unsplash.