In this blog article, I want to introduce you to how to use GitHub Actions to automate boring repetitive tasks and spend more time coding.
If your codebase is already on GitHub, you can start right away and manage the entire workflow in a single place in the future. No more tedious configurations spread across different platforms and services.
- How do GitHub Actions work?
- Hands-on: We’re building a workflow!
- The Marketplace
- Your start
How do GitHub Actions work?
If we look at a GitHub repo, various events can occur. For example, someone may create a pull request, gives the repo a star, or an issue is created.
These events — you can find a complete list here — can trigger one or more workflows. Workflows run on virtual machines in the cloud and are provided by GitHub. You specify what steps these machines perform to automate your tasks.
GitHub actions are often used to run test suites, create Docker images and push them to a registry, or run a security scan on release-ready versions to check for vulnerabilities.
You don’t have to worry about costs in the process, as GitHub has a very generous free tier. Public repositories are even completely free of charge.
Hands-on: Let’s build a workflow!
Let’s take a closer look at a workflow and how to build it.
To make a workflow visible to GitHub, you need to have a folder named .github in your repo, which in turn needs to have a folder named workflows. You can now create your workflows in exactly this folder.
All workflows are stored in YAML files. So let’s create an integration.yml file to get started.
A good starting point for working with GitHub Actions is to implement a simple CI pipeline. Our app in this case could be a Node.js application that hosts an HTML page, includes some javascript, and is built using Webpack.
In addition, we use the testing framework Jest to test if our code works properly. The workflow is to be executed when someone initiates a pull request on the main branch.
Until now, before creating a pull request for their branch, each developer has to independently install the node modules on their machine, run the tests, and execute the build script.
These repetitive steps are now automated and serve as an incentive to push smaller pieces of code iteratively.
We give our workflow the name Node continuous integration. We then specify the events for which this workflow will be executed. Each workflow has at least one job. All jobs are bundled under the jobs object.
We name it test_pull_request . The runs-on command determines the operating system of the VM. It then runs through all the steps that the developer would otherwise run manually.
Notice:
Each job runs on its own VM instance. This means that you do not access a shared folder for different jobs. Steps are processed sequentially per job, whereas jobs run in parallel by default.
You may already be wondering what is behind the command — uses actions/checkout@v2, for example, and why exactly this syntax is needed. I will explain this in the section Marketplace.
The Marketplace
Basically it is possible — as also shown in later steps — to execute command-line commands directly. Since setting up Node environments or importing source code is common, there are pre-configured blocks.
These summarize all the tasks required for the purpose. So it is always worthwhile to look in the dedicated marketplace first. You may already find an action and save yourself an afternoon of question marks and headaches.
Here you can find not only official actions created by GitHub, but also actions created by the community for everyone to use …
But before we lose the thread, quickly back to our workflow.
Behind the action/checkout@v2 hides a GitHub-created way to completely copy its current repo (with current commit) to the current VM. “@v2” stands for the version here.
The next step sets us up with a version 16 node environment. Then we install the dependencies, test the code and run the build script.
But where do I find my actions, workflows, and results? In the main bar of your repo!
After clicking on the Actions tab, an overview of all workflows will open. On the left side, all workflows available in the repo are listed. In the middle, you can find workflows that are currently running or have already run (workflow log).
If there were no errors, you will see a green checkmark, the other way around a red X.
This all sounds abstract and you don’t even know what exactly the problem was, should an error occur?!
No problem, just click on a workflow from the workflow log and you will get an overview of the process. It is listed exactly which steps the VM has executed and you can see at which steps there were problems.
Then you fix the errors that occurred, create a new commit and restart the workflow. If everything has now worked, you will see a green checkmark under Workflows as well as in your pull request.
Now it is time that you start with Github Actions
