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.

A CI-system is something mandatory, in my opinion, for each software project. So the switch seems to be appropriate. But 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 uploaded the result 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 in master took 44 minutes and 28 seconds without queuing time! We are talking about compiling 15 C++ files or so and executed 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 service in the past!

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 has 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 build in the container and others in the normal macOS or Windows environment. However, that seems not 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 did check that everything runs fine again I also looked at all the DockerHub images. Much to my surprise it showed 1.3k pull for the cppinsights-builder. It looks like other people 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 other platforms than macOS but I would like to catch crashed 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. It is also possible that I 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 Patreon or of course contribute with code.

Andreas