BOINC client release workflow status

Recently we released a new version 8.2.9 of BOINC.

Today I would like to talk a little bit about our release procedures and the improvements we have made to them over the last few years.

At the moment we support 4 platforms: Windows, Linux, macOS, and Android.

Android

In the early days, to build Android you had to have a dedicated environment (Valgrind or a regular Virtual Machine) in order to build the BOINC client for 6 architectures: arm, arm64, x86, x86_64, mips, and mips64. Later we dropped mips and mips64 as there are no devices on the market that run Android OS on these CPUs. Instead we introduced separate armv6 and armv7 builds, because there are still some devices based on these architectures.

And, of course, to build the BOINC Manager, which was written in Java, you had to have Android Studio installed with the configured Android SDK.

So, to make a release you had to build the latest versions of the BOINC client for all supported architectures, put these builds into the source project folder of BOINC, and then build the BOINC Manager in Android Studio.

The next important step was to sign the APK file and test the release on either virtual or real devices.

The final step was to publish the release on the Play Store.

As you can see, this process required quite a lot of manual work.

My goal has always been to automate it as much as possible to save time and avoid human errors.

That is why we have now automated quite a lot of this.

When a new release tag is pushed to the GitHub repository, it triggers the GitHub Actions workflow that builds the BOINC client for all supported architectures and then builds the BOINC Manager. Before the final APK is uploaded, the CI workflow runs a set of unit tests to make sure that the BOINC Manager behaves as designed.

Of course, it would be great to run some BOINC client tests as well, but this is not yet implemented.

APK signing is currently done manually. The main reason is that I don't want to put the binary signing keys in the CI environment. I have in mind a more secure solution for that, but it is not yet implemented.

Historically we built the BOINC client dependencies using hand-written scripts, but this was too hard to maintain and update, so we switched to the vcpkg package manager, which allows us to have a very consistent build environment for all supported platforms, since we use the same vcpkg configuration across all platforms.

Now for the most interesting part. As I mentioned before, we are not able to publish Android BOINC on the Play Store because of the requirement to use the latest version of the Android API, which doesn't work for us. That is why Android BOINC is currently published only on the official BOINC website and on F-Droid (a third-party service not supported by us).

F-Droid is a great service, but it requires a slightly different approach to building the APK. In order to get a new release on F-Droid, I manually create a pull request to their repository with the updated script that is used to build the BOINC APK on their side. This is a step that cannot be automated, but it usually takes just a few minutes, and then F-Droid maintainers typically merge the PR within a day or two, after which the new release becomes available on F-Droid as well.

F-Droid does not have separate channels for releases, so we push only the stable release there.

Linux

Historically, we supported only a shell script with an attached binary for Linux, but this approach was never ideal since you need to use a separate virtual machine with a very old version of Linux to build the BOINC client with as old a version of glibc as possible in order to cover the majority of Linux distributions.

This also required quite a lot of manual work and was inconvenient for users, since they needed to download the new release, run it, and then follow the instructions to install it.

Every Linux distribution has its own package manager, and for quite a long period of time we relied on volunteers to maintain packages for different Linux distributions.

As I mentioned before, we decided to maintain our own Linux packages for the most popular Linux distributions.

Currently we support the following Linux distributions:

• Debian (10, 11, 12, 13)
• Ubuntu (20.04, 22.04, 24.04)
• Fedora (37, 38, 39, 40, 41, 42, 43)
• OpenSUSE (15.4, 15.5, 15.6, 16.0)
• Mint (20, 21, 22)
• Mint Debian (4, 5, 6, 7)

built for x64, arm64, and armv7 architectures.

The process of building Linux packages is also automated and is triggered by a new release tag in the GitHub repository. The CI workflow builds the BOINC client for Linux and then builds the packages for all supported Linux distributions. After that, the packages are uploaded to our repository, and users can install them using their package manager.

What is also quite important is that we run a set of tests to make sure that every particular package can be installed and works as expected on the corresponding Linux distribution. This is done using GitHub Actions and Docker containers with the corresponding Linux distributions. Besides that, we also run tests that verify the newest package can be installed on top of a previous version, even if that previous version is not the latest one or was installed from a different source (for example, from the distribution repository). This is very important for ensuring users can update their BOINC client without any issues.

It is also worth mentioning that we build our software almost entirely with static libraries, so we don't have to worry about dependencies on users' machines. This also allows us to support a wide range of Linux distributions with different versions of glibc and other libraries without any issues. To do this we use the vcpkg package manager to manage our dependencies and build them as static libraries. This also gives us a very consistent build environment across all supported platforms, since we use the same vcpkg configuration for all of them.

At the moment this is the only workflow that is fully automated, and we are very proud of it, since it saves us a lot of time and allows us to provide the best experience for our Linux users. We are planning to support more Linux distributions in the future, and we will continue to improve our CI workflow to make it even more efficient and reliable. The only manual step is to promote the new release from the alpha channel to the stable channel, but we have a dedicated CI workflow for that which needs to be triggered manually. And this is quite a simple and easy process.

Besides that, we support several other package managers for Linux, such as Flatpak, Snap, and Guix.

Flatpak uses their own infrastructure to build the packages, so similar to F-Droid we simply create a pull request to their repository with the updated script that is used to build the BOINC package on their side.

Since Flatpak does not have separate channels for releases, we push only the stable release there.

The Snap package is built and tested in our CI workflow and is also completely automated. The only manual action required is to promote the new release from the beta channel to the stable channel, but this is just a few clicks in the Snapcraft dashboard.

Guix is similar to Flatpak and F-Droid — we simply create a pull request to their repository with the updated script that is used to build the BOINC package on their side. Guix also does not have separate channels for releases, so we push only the stable release there.

Windows

To build the BOINC software for Windows, Visual Studio must be installed. Historically, we supported several versions of Visual Studio, but at the moment we support only the latest version (Visual Studio 2022, with plans to move to Visual Studio 2026 soon). The other story is with the installer. We had been using InstallShield for a very long time, running on a separate virtual machine with Windows XP. Since we wanted to support not only the x64 version of Windows but also arm64, we had to create our own installer that is built using the latest version of Visual Studio and supports both x64 and arm64 architectures. The process of building the BOINC software for Windows is also automated and is triggered by a new release tag in the GitHub repository. The CI workflow builds the BOINC client for Windows and then builds the installer for both x64 and arm64 architectures. As the penultimate step, the installer is signed using the Azure signing solution, which is also completely automated. The only manual step is to publish the new release on the website. There is a way to automate this step as well, but at the moment it takes just a few seconds, so we don't see a strong need to automate it.

Similar to Linux, during the CI workflow we run a set of tests to make sure the installer can be installed and works as expected on the latest Windows version for both x64 and arm64 architectures. These tests cover not only fresh installations but also updates from a previous version.

Builds for Windows are also statically linked with their dependencies, and similar to Linux we use vcpkg to manage them. This is different from the old approach where there were prebuilt dependency binaries that were very hard to manage and update. With vcpkg we have a very consistent build environment across all supported platforms, since we use the same vcpkg configuration for all of them.

macOS

This is the only platform for which we do not build the release on CI. It is also the only platform that does not use vcpkg to manage dependencies. We do have plans to move in the direction of unifying our build system for all platforms, but we are not there yet. We do have CI workflows that build the BOINC client and manager for macOS, but they are used only during the development process to ensure that changes don't break the build on macOS. The process of building the BOINC software for macOS is still manual and requires a Mac with the latest version of Xcode installed. The installer is also built using the latest version of Xcode and uses a special set of scripts to sign and build the complete installer package. The final step is to publish the new release on the website, and similar to Windows this step is not automated either, but it takes just a few seconds, so we don't see a strong need to automate it.