Securing quality in codebases as you build has become a seamless part of the development lifecycle. Solutions through testing, linting, and prettier make it almost impossible not to be able to enforce standards that are applied from commitment to merging. More so on the latter, the most protected process in standard defense would have to be protecting core branches from faulty code being merged in. To enable this we have workflows, more specifically related to probably the most popular git platform, with Github we have actions.
What Are Github Actions
Generally speaking, Github actions are git workflows. Git repository platforms typically have some way to perform actions based on conditions related to a branch or pushing up a new commit. For better context, think of a pre-commit hook in your repo. Now take that same concept and apply it to your cloud Git repository. For the rest of the article, let’s keep that being Github.
How To Set Them Up
So actions are written in.yml files found in the .github/workflows directory at the root of your project. YAML, .yml as mentioned earlier, is not a programming language. It is meant to be language agnostic, and a human-readable option for data serialization. It is very easy to follow, and in Github actions, highly flexible to establish conditional use with.
Moving into the actual file, as mentioned is very simple and easy to follow. Below you’ll find a simple example.
name: 'Code Quality'
on: [pull_request]
jobs:
linting:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
........
........
........As you can see above everything is straightforward and easy to understand. Workflows start with a name, then roll into specifying jobs and what OS should they be run on. From there you’ll find the steps, which define actual actions performed. From the example, specifically the line with actions/checkout@v2, you’ll also see an important piece in powering actions. Plugins.
Github Action Plugins
Plugins are pretty similar to packages. They exist as bundled logic in a Git repository when they can be used by reference in your workflow file. To illustrate this, let’s look back at our example. As you can see we’re using a package called actions/checkout@v2. This is a common plugin used to check out the code of your PR into the CLI environment of your workflow. For those unknowingly thinking that this isn’t necessary, or that they’d be better off doing it on their own, actually take a look at the raw code of the main file for the plugin.
That’s a lot! Much like the packages we use to speed up development with reliable, well-tested, and open-source contributed code, these plugins do the same for our workflows.
In Closing
Introductions are meant to be short, sweet, and leave you hungry for more. That’s the point here. For those unfamiliar with workflows or any of the concepts here, a finite brief before getting deep down into the details is always preferred. However, next time, we’ll be breaking down what a fully written workflow file looks like.