Github Actions, C++ with Boost and cmake, almost a 50% speedup with caching

For a personal project I use Github for source code hosting and Github Actions as an automated build and test tool. Github Actions compiles my cmake project and runs all the unit tests on every commit. It also saves a build artifact, the actual compiled program. By utilizing some dependency caching and make flags I sped up the build process by 43% by caching the apt install libboost1.65-dev and giving cmake a -j2 makeflag.

The improvements to the build script show the faster build time

This article shows my simple setup to compile a C++ project with cmake and Boost on Github Actions. After compilation, it runs all the tests and uploads the compiled binary for download. For my one man project it's overkill, but when collaborating or when builds take a long time on your own machine, it's great to have an automated build / test system.

If you like this article, consider sponsoring me by trying out a Digital Ocean VPS. With this link you'll get $100 credit for 60 days). (referral link)

Do note that the build time decreased from 1 minute 48 seconds to 47 seconds for a small C++ project. The percentage wise speedup is large, but probably you might find the title a bit clickbaity. The main focus of this article is to show how to build a simple C++ project with Boost included using github actions.

It also shows how to cache an apt install and how to provide cmake with the MAKEFLAGS to utilize the two cores that the free github builder virtual machine has.

At work we use Gitlab CI for this and it cuts compilation time of the entire project from 2 hours to 20 minutes due to humongous build servers running gitlab runners. A few different binaries are built for different arm architectures, the test suite is run, doxygen docs are generated, code style checks are done and static analysis is done with Sonarqube, all from one source. With a team of developers this all gives an enormous speed increase in the process of reviewing code and not forgetting certain things.

I don't have my own gitlab server running (anymore) but I noticed that github also have a feature like gitlab ci, but they call it Github Actions, and it's free for public projects, for private projects you get a limited amount of time, but 2000 minutes is enough for me.

Simple cmake C++ project with Boost on Github Actions

If you host your source code on github, you can use Github Actions. Most of my personal projects follow this simple cmake structure which integrates well with my preferred IDE, CLion by JetBrains. The structure also has unit tests with GoogleTest.

For Boost integration, check my other article on integrating that in the project setup. On Ubuntu you also need to install the development libraries:

apt install libboost-dev-all

The Github linux virtual machine that will build the project does have most C++ development tools installed (like gcc and the build-essential package) but boost is missing. In the file you write which specifies your build steps you can also use sudo to install packages via apt , in our case boost .

Basic workflow

In the root folder of your project, create a folder for the workflow files for github:

mkdir -p .github/workflows

In that folder, create a .yml file for your workflow. My basic example to run cmake and my unit test is listed below.

name: build and run tests
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    # install dependencies
    - name: boost
      run: sudo apt-get update && sudo apt-get install -yq libboost1.65-dev
    # build project
    - name: mkdir
      run: mkdir build
    - name: cmake build
      run: cmake -Bbuild -H.
    - name: cmake make
      run: cmake --build build/ --target all
    # run tests
    - name: run test 1
      run: build/tst/Example1_tst
    - name: run test 2
      run: build/tst/Example2_tst

If you commit and push, you should be able to look up the action on Github:

That was easy wasn't is? A remote server builds your program and runs the unit tests. If you would do this on your local workstation the steps would be a bit like:

#build code
cd to/project/folder
cd build
cmake ..
make
# run tests
tst/Example1_tst
tst/Example2_tst

Caching the apt install dependencies

In my case the apt update && apt install libboost-1.65-dev takes almost 15 seconds. If you have more packages, this takes longer and its also run every time, but almost never changes. So a bit of a waste of time and resources.

This post on Stackoverflow has an elaborate example on caching apt steps. My example is a simplified version. Replace this step in your workflow file:

- name: boost
  run: sudo apt-get update && sudo apt-get install -yq libboost1.65-dev

With the following piece of code:

- name: Cache boost
  uses: actions/cache@v1.0.3
  id: cache-boost
  with:
    path: "~/boost"
    key: libboost1.65-dev
- name: Install boost
  env:
    CACHE_HIT: ${{steps.cache-boost.outputs.cache-hit}}
  run: |
    if [[ "$CACHE_HIT" == 'true' ]]; then
      sudo cp --force --recursive ~/boost/* /
    else
      sudo apt-get update && sudo apt-get install -yq libboost1.65-dev
      mkdir -p ~/boost
      for dep in libboost1.65-dev; do
          dpkg -L $dep | while IFS= read -r f; do if test -f $f; then echo $f; fi; done | xargs cp --parents --target-directory ~/boost/
      done
    fi

What this basically does is, if boost is not installed yet, install it and then use dpkg to copy all newly installed files to a folder. The next time, the virtual machine will download that artifact and just extract it on / . The effect is the same, the libraries are installed, however the time it takes is just 1 second instead of 15 seconds.

If you need to install a newer version of the package, say, libboost-1.71-dev , replace the package name by the newer one and you're done.

If you have multiple packages to install, make sure they're the actual packages, not a meta-package (a package without files, just dependencies). Meta-packages don't have files to copy, so the steps will fail. You can use the Ubuntu or Debian packages site to check, for example libboost-dev is a meta-package (10 kB package size, no actual files ) where as libboost1.71-dev is an actual package. Larger file size and lots of included files .

With this first improvement, subsequent build will be faster, especially when you have lots of dependencies to install. One more optimalisation we can do is provide a makeflag to use more resources during building.

Provide makeflags to cmake

In a cmake project, the build steps can all be done using cmake itself instead of the build system cmake generates for (like make/ninja), if your cmake version is 3.15 or higher ):

cd to/project/folder
cmake --build build/
sudo cmake --install build/

No seperate make , the last cmake command wraps around that. You can also just do it the old fashioned way:

cd to/project/folder/build
cmake ..
make all
sudo make install

Using the cmake commands works not only for Makefiles , but also for ninja or any other build system cmake can generate.

But, in our example, we use Makefiles and to use the two cores the github virtual machine has (instead of just one core) we must provide a flag to make .

If you would do it with the commandline you would do this:

make -j2 all

Where -j# is the amount of cores you want to use to build. Now with cmake we can do more complicated things in our CMakeLists.txt , but that would clutter up our simple example. Github Actions allows you to set environment variables and make can use the MAKEFLAGS environment variable. If we set that to contain -j2 , even via cmake , the flag will be passed through.

In our github actions yaml file, replace the following step:

- name: cmake make
  run: cmake --build build/ --target all

With the following code. You could also just add the last two lines instead of replacing the whole block.

- name: cmake make
  run: cmake --build build/ --target all
  env:
    MAKEFLAGS: "-j2"

In my case using two cores sped up the build process by another 27 seconds. If your project is larger, the improvement will be bigger as well.

Upload build artifacts

One of the other usefull features is to be able to download certain files that were built. Github calls them build artifacts and you can download them via the webpage:

At work, via Gitlab, we use this to cross compile for a few different ARM architectures. Not everybody has a crosscompiler setup, but they can just download their freshly built binary and run it on actual hardware. Most of our testing is automated with unit tests, but there are edge cases, for example, interaction with actual hardware (think valves, pumps, high voltage relais).

If you don't crosscompile, it is still useful, it allows other people to get a binary without having to compile it. A tester could login, download the binary for their specific feature branch and use it for testing.

Build artifacts are also reproducable. You can trigger a build of a branch from 6 months ago and get that binary, just as pristine as it was back then.

Add the following to the bottom of your yml file. The paths are for our example.

# upload artifact, example binary
- name: Upload Example binary
  uses: actions/upload-artifact@v1
  with:
    name: upload binary
    path: build/src/Example

You can go crazy with this, couple it with github releases for certain branches and automate more, but that is out of scope for our example case.

The final yaml file

The yaml file with all improvements is listed below:

name: build and run tests
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    # install and cache dependencies
    - name: Cache boost
      uses: actions/cache@v1.0.3
      id: cache-boost
      with:
        path: "~/boost"
        key: libboost1.65-dev
    - name: Install boost
      env:
        CACHE_HIT: ${{steps.cache-boost.outputs.cache-hit}}
      run: |
        if [[ "$CACHE_HIT" == 'true' ]]; then
          sudo cp --force --recursive ~/boost/* /
        else
          sudo apt-get update && sudo apt-get install -yq libboost1.65-dev
          mkdir -p ~/boost
          for dep in libboost1.65-dev; do
              dpkg -L $dep | while IFS= read -r f; do if test -f $f; then echo $f; fi; done | xargs cp --parents --target-directory ~/boost/
          done
        fi
    # build project
    - name: mkdir
      run: mkdir build
    - name: cmake build
      run: cmake -Bbuild -H.
    - name: cmake make
      run: cmake --build build/ --target all
      env:
        MAKEFLAGS: "-j2"
    # run tests
    - name: run test 1
      run: build/tst/Example1_tst
    - name: run test 2
      run: build/tst/Example2_tst
    # upload artifact, game binary
    - name: Upload Example binary
      uses: actions/upload-artifact@v1
      with:
        name: upload binary
        path: build/src/Example

Conclusion

This article discussed both the automated build setup of a C++ project on Github actions, how to upload build artifacts and two improvements to speed up such a build. In my case the improvements are significant percentage wise, but not that impressive if you look at the actual numbers. In the case of larger projects, or when you are billed for runtime, the improvements could have a bigger effect.