Continuous Integration is Simple. GitHub Actions

Hello dear reader!

All our lives have things that are embarrassing to remember about, not something to tell. Nevertheless, I have to say: until recently, the coding-interview repository hasn’t used continuous integration capabilities. “What a disgrace!” – they will shout. “But who needs it at all?!” – others will object.

For my part, I propose to work out together why developers are increasingly using modern tools for continuous integration, instead of starting a fire rubbing two sticks together, and to add continuous integration into the coding-interview repository using GitHub Actions.

So what continuous integration is?

Continuous integration (CI) is an approach that involves making frequent changes to a codebase for identifying errors as quickly as possible, including during the integration process.

“Where are tests?” – an attentive reader will ask. Well, if the reader asks, why not answer? Tests are just one of the capabilities of detecting errors during frequent changes, making the process of continuous integration even more reliable. Therefore, de facto tests are just a part of the continuous integration process itself.

Today, there is a huge number of tools that simplify the process of continuous integration: Jenkins, Travis, Teamcity, GitLab CI/CD, GitHub Actions and others. Since our repository is located on GitHub, we will continue our acquaintance with GitHub tools, although the idea itself is the same everywhere:

1. Determine the events that will activate certain jobs when changes to the common code base are made;
2. For each job, determine the set of actions (steps) that must be performed in the context of this job.

GitHub Actions are configured using a configuration file in the YAML format, which should be located in the .github/workflows/ directory. Here is an example configuration file:

name: cs-solvers

on: [push]

jobs:
  test:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Setup cs-solvers
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 3.1.101
    - name: Build cs-solvers
      run: dotnet build cs-solvers --configuration Release
    - name: Test cs-solvers
      run: dotnet test cs-solvers

In general, these configurations themselves are quite informative, but let’s give some explanations:

• on: [ push ] describes the list of events that should activate this workflow. The conditions for events’ activation triggers can be specified more strictly, for example, by the names of branches on which these events should or shouldn’t be called;
• jobs describes the list of jobs that must be performed in the context of this workflow. In our case, we only created the job test;
• runs-on: ubuntu-latest determines the type of machine to run the job on;
• steps describes the list of actions (steps) to be performed:
  • actions/checkout@v2 clones the source code to the execution server;
  • actions/setup-dotnet@v1 sets up the environment dotnet;
  • dotnet build cs-solvers --configuration Release builds our project;
  • dotnet test cs-solvers runs tests.

To see the result of the workflow, select the Actions tab inside the repository:

And select the workflow of interest:

It remains to add to the root of README.md file a link to the result of our workflow in the format:

![BADGE_NAME](https://github.com/<OWNER>/<REPOSITORY>/workflows/<WORKFLOW_NAME>/badge.svg)

That is, the following line:

![cs-solvers](https://github.com/itdranik/coding-interview/workflows/cs-solvers/badge.svg)

As a result, we get this beautiful status icon below in the project description.

It’s just so grown-up serious! So, I think it’s time to say goodbye. Good mood and stable builds!