Getting started with Github Actions

The need to have automated our integration (IC) and our deployments I think is something beyond doubt. And I’m sure you’ve heard about a lot of tools, so we want to talk about one of them, for your Github repositories, which is the recent Github Actions.

So, in case it’s not clear yet, Github Actions is the tool to automate CI/CD streams from our Github repositories. But where do we start working with Gihub Actions?

GiHub Actions Pricing

The first thing that I’m sure many of you are worried about is: how much does it cost? The best news is that it’s free to start working. With all Github accounts, we have up to 2,000 working minutes per month, which is basically computed by adding up the runtime of all our flows per month. From here, if we need more, we can move on to any of Github’s payment plans to make the most of.  And now that we’ve talked about the economic issue, let’s get started.

Github Actions Introduction

There are going to be several things we need to get started with Github Actions:

1. A Github account and repository.
2. YAML files defining our workflows, within the repository.
3. A Github compiler agent.

YAML files defining our workflows in GitHub Actions

You’ve probably run into YAML files before in your life as a developer. These files, whose structure is based on spaces and/or tabulations, allow us to define our CI/CD flow, after all, these flows are a series of actions that are executed in a certain sequence, to generate our applications (whether binary or for example Docker containers), and then deploy them.

Github Actions defines a YAML structure to execute these sequences. By convention we will save these files, in our repository, under the folder .github/workflows and we can have as many as we want inside our repository, an example of a very (but very) basic file to generate an application. NET Core, could be this:

In this simple example we see the following parts:

1. We define the name of our flow (.NET)
2. We define what events within the repository are going to cause the execution of this Workflow (more information)
3. And then we define the collection of works. In this case, only one: build, which in turn has the following structure:
   1. The agent (discussed below) where the sequence of steps will be executed, in this case Ubuntu-latest.
   2. Typical actions of an application .NET Core, which are the tasks to execute: Framework setup (5.0) of .NET Core, dotnet restore your dependencies, dotnet build, and of course test execution.

As I was saying, these YAML files must be in the default directory, but the easiest way to create them is through the Github web interface. From the home of our repository, click on Actions and then on new workflow.

When creating a Workflow, there are predefined templates, but we can also start one from scratch, if we choose .NET Core, which is the example above, we will be shown an edit window:

From here, we will edit the file and add the sequence of tasks we want. Look to the right, we have tasks already created by Github itself or third parties to do everything we need: generate Docker containers, publish artifacts, deployments to any of the main clouds… But well, we will talk about flows and tasks in other articles. If you want to see more about YAML syntax, you can consult it.

Hopefully, and a little work, we’ll have our YAML file that will compile (and optionally deploy) our application. But before we talked about what we needed an agent, right?

Compilation and deployment agents

As we said initially, and as we saw in the YAML, we need an agent where all these steps are executed. In the example we had, in line 12, this: runs-on: ubuntu-latest. This will tell the Github Actions engine that the steps of that job have to run on an Ubuntu machine, but where does that machine come from?

The good news is that Github itself dynamically puts at our disposal various compilation agents that we can choose to run our flows. And these are:

• Windows Server 2019: Windows-latest o Windows-2019
• Ubuntu 20.04: Ubuntu-latest or Ubuntu-20.04
• Ubuntu 18.04: Ubuntu-18.04
• Ubuntu 16.04: Ubuntu-16.04
• acOS Big Sur 11.0: macos-11.0
• macOS Catalina 10.15: macos-latest or macos-10.15

All these agents have a number of technical features of hardware and installed software, which you can check here. But even so, if those agents do not meet your needs for hardware or software, you can also install the Gihub Actions agent in your own environments. Here are the instructions creating a self-hosted runner.

There is much more about Github Actions, for now, we wanted to give you this series of initial concepts so you can start testing them, as well as this link, where you have detailed instructions and examples.

Of course, in future articles, talks and even workshops, we will be talking more about Github tools, such as Github Actions. If you want to know more, here you have our webinar  “Your first steps with GitHub”, totally free.