GitHub is the repository we use in Blexin to version our code. Accordingly to DevOps principles, most of these projects have one or more pipelines that help to improve the quality of the code and to reduce the technical debt. Among different DevOps practices, we adopted for most projects Continuous Integration processes, often related to Pull Requests (PR).
The pull request process is critical for us: it is based on a review related to newly implemented features in order to improve it and to help developers increase their technical expertise.

During the creation of a PR or after its closure, we set automation processes helping us to verify the correctness of the code compiling and the successful execution of tests. These automation processes are executed, at date, through Azure Pipelines, which allows us to set some triggers linked to given events (i.e., push, pull request), causing the launch of a build.

Following the takeover of GitHub by Microsoft and the introduction of GitHub Actions, I wonder if it could be possible to integrate some ongoing processes, as the validation process on a PR, directly on GitHub. In this article, I show you how I create this process for Raptor, the persistence layer, which uses our CMQ WebRight.

Before going on, we must distinguish Azure Pipelines from GitHub Actions: today, these lasts don’t have the flexibility and the features we can find in the first ones. Actions would surely have a bright future, but Azure Pipelines remain the most suitable choice for structured workflows.
Another aspect to consider is the price: it is free for public repositories, and for private repositories there’s a free tier, with a limitation to 2000 minutes of build, enough to test and start practice.

In the following Figure 1, I show how I set an Action of ours. Once on GitHub, I select the new tab Actions in the repository:

Figure 1

I select the voice New Workflow on the opening page, and I arrive at the page in Figure 2. Here I find some template of workflow, based on the technology used in our project (Angular, in my case).

Figure 2

I select Simple workflow, and I can display an editor allowing me to modify the build-process at my will, and set required steps. The whole process is defined using YAML.

Figure 3

In figure 3, we can underline the following sections:

1. A text box for the name of our YML file: we can give a name to our process
2. An operational editor, which helps us to define workflows, thanks to intellisense
3. A section with a list of available steps to insert in the action and a section related to the documentation. Most of the steps that can be imported in the action originate from the community, thanks to the presence of a marketplace

Inside the build process, I added the following command to those already present:

1. Install the Angular CLI on the agent to run the project build
2. Change the present directory moving in the project folder
3. Running the npm install
4. Running the build with the command npm run-script build

Some interesting parameters in the process are:

• The section on (row 2), where it is possible to define some triggers of my workflow. In my case, the action starts with a push on a defined branch or with the creation of a PR on the branch master
• The section runs-on, which defines which agent type runs my build. GitHub makes available different agent types, based on needs
• The section matrix, where I can specify frameworks combinations on which I run my workflow (i.e., different versions of NodeJS)

This process allows me to compile the code and verify possible errors. I just need to save the YML file with a commit in an ad-hoc branch, which I call cicd and let the first build to run, as in Figure 4:

Figure 4

Summarizing, I can create a build in a few minutes, which allows me to validate the code used and submitted through a push operation, or in a PR. If we have a PR, during the creation process and at the end of the running of the action, the result would be similar to:

Figure 5

Finally, the aspect of Actions I most like is that they are not linked to the code validation, but many of them help to automate repetitive and boring tasks, such as those related to the ChatOps world (look at Figure 6)

Figure 6

Happy Actions to everyone!