Blog

A while ago, Travis CI informed me (and others) that travis-ci.org will be shutting down, and all projects have to move to travis-ci.com (or something like this). A call to action.

C++ Insights and Travis CI

Travis CI was there since the beginning of C++ Insights back in May 2018 (8f1f0ea9c). Currently, the master build shows the build number 1118. For those who don't know online CI systems, a good portion of these builds was fighting with the configuration and other setup stuff. Nonetheless, I think the number is great.

In my opinion, A CI system is mandatory for each software project. So, the switch seems to be appropriate. However, the CI pipeline of C++ Insights is a bit more complicated than a single repository. Once the C++ Insights binary is built, it triggers a new build of the C++ Insights container, which then is uploaded to DockerHub, from which the web-server pulls the latest image. That means that it is not just one repository to update but a chain. The same is true for the web-fronted repository.

While I'm grateful for the free service of Travis CI in the last two years, the build times increased a lot over time. The macOS and Windows builds are terribly slow. The last build of master took 44 minutes and 28 seconds without queuing time! We are talking about compiling 15 C++ files or so and executing a little less than 400 test cases. In the last few months, I often forgot that I had pushed a change due to the extensive build time. Now that they are requesting a change anyway, I looked around and decided to switch to GitHub Actions. So thank you, Travis CI, for your past service!

Switching to GitHub Actions

GitHub Actions did provide all the different things I needed. I can trigger builds of other repositories thanks to repository_dispatch, run custom containers, has support for Linux, Windows, and macOS. Perfect.

One very cool feature is that I can execute all the steps in a specific container. In this case, andreasfertig/cppinsights-builder. With Travis CI I had to write additional wrappers and ifs to get that working. But maybe I missed something there.

The next thing was that the Windows VM already had all the things I needed for C++ development installed. Visual Studio and all that it needs to compile a C++ project.

A neat trick I saw somewhere on the internet is to (mis)use cmake as a shell. This helps greatly to write cross-platform steps without the need to install additional packages or lookup what the equivalent of curl under Windows is or how a file can be unpacked there. Yes, I'm not much of a Windows user.

The one caveat is that once a container is specified for a job, everything runs in that container. My use-case would be more to run some builds in the container and others in the normal macOS or Windows environment. However, that does not seem possible at the moment. I had to duplicate a lot of code in the yml-file, and now there is a job that builds the macOS and Windows binary and tests it, and a second job that builds the Linux binary and runs all the different tests.

I do run more parallel builds now and execute the test cases on Windows as well, with a total build time of around 10 minutes!

I hope that this change lasts for longer than two years. It took me more than two days to figure out all the details and around 160 try-pushes before everything worked (let's see if that is true).

The C++ Insights Builder Container on DockerHub

When I checked that everything ran fine again, I also looked at all the DockerHub images. Much to my surprise, it showed a 1.3k pull for the cppinsights-builder. It looks like other people are building C++ Insights as well.

What's next

I would love to have code coverage from the Windows build. Currently, the Windows builds use only MSVC for building. If someone knows how code coverage information can be retrieved from these builds and uploaded to codecov.io, please let me know, or even better, send me a PR!

For building the insights binary under Windows with Clang there seems to be a way code-coverage-with-clang-on-windows.html. However, recent Clang installations seem to miss some libraries.

I would also like to change the test runner in a way that tests can fail on platforms other than macOS, but I would like to catch crashes and let the build fail in that case.

What's missing at the moment is the clang-tidy check that was performed on Travis CI. I need to look into that. I could also restructure the pipeline and let the clang-format check run in parallel with the other builds.

Support the project

You can support the project by becoming a GitHub Sponsor or, of course, with code contributions.

Andreas