MariaDB Buildbot

What is it?

Buildbot.mariadb.org is the continuous integration testing platform developed and managed by the MariaDB Foundation as well as its contributors. It is based on the Buildbot.net open-source testing framework. By streamlining the testing process and providing real-time feedback, it helps the developers of MariaDB Server to catch potential issues early on and ensures the code quality for all releases.

With more than 100 builds running at pretty much all times, it covers a multitude of different configurations for the following platforms:

• x64 and x86
• ARM64 (aarch64)
• PowerPC (ppc64le)
• s390x

and all currently supported versions of the following operating systems:

• Debian
• Ubuntu
• Fedora
• CentOS & CentOS Stream
• RHEL
• AlmaLinux
• Rocky Linux
• SLES & OpenSUSE
• Windows
• AIX

It is an important part of preparing all releases of MariaDB Server and not only providing functionality but also version upgrades testing. Constant improvements are done to ensure better resource allocation as well as maintaining the relevant platforms for the userbase.

• You can find the configuration files on the dedicated repository on GitHub.
• For an introduction to the Buildbot framework, check out their tutorial.
• Relevant information and topics can also be found and discussed on the public Buildbot channel over on Zulip.

Starting from January of 2025, Buildbot releases can be found on the MariaDB Foundation Development Jira project (MDBF) covering all included Jira items (an account is required to see the release information).

Another tool allowing for easier filtering of the tests results is CrossReference, developed locally by the MariaDB Foundation.

---

The hardware used by the MariaDB Buildbot is provided by the following sponsors whom we thank for their continued support:

---

How does it work?

In order to cover this part we should first cover a few notions which will make it easier to start understanding the Buildbot platform:

• Master – this is the central component which orchestrates which Builds run on which Workers.
  • Tracks changes in the monitored repository, such as new commits.
  • Monitors the build run status and collects the results to be presented in the web interface.
  • The MariaDB Buildbot uses setup with multiple Masters, each suited to a different architecture or components to be tested.
• Worker – the component used for executing the commands provided by the Master.
  • Runs the Build steps after retrieving the changes in the repository or by a manual request.
  • One Worker can run multiple Builds in parallel.
  • One Master can orchestrate Builds on multiple Workers depending on their availability.
  • Local Workers are always running and connected to their correspondent Master
  • Latent Workers are started by the Master when a Build is queued and stopped when they are no longer needed
• Schedulers – assigned to each Master, these are the components that decide when a Build should be started
  • They create the BuildRequest which ties the relevant code version in the repository to the correct Builder
• BuildSet – a collection of potentially not yet created Builds
  • All Builds under a BuildSet run on the same code version
  • Includes multiple Builders (for example, can be used to run the same code change on different operating systems)
• Builder – takes the BuildRequest created by the Scheduler and assigns the Build steps to an available Worker
• BuildFactory – the definition and order of the steps performed in a Build
• Build – the executed instance following the steps defined in the BuildFactory

More detailed explanations for these concepts can be found in the official documentation.

On the next picture we will show a simple example of how a change is processed until the build starts executing:

1. User commits a change and submits a pull request.
2. The change is picked up by the master.
3. The Scheduler creates the BuildRequests and groups them in a BuildSet:
4. Now we have 3 Builders which are going to wait until their compatible Workers will be available.
   • Worker X is available and can run the Builds from Builders A and B in parallel.
   • Worker Y is currently busy with another Build and can only run one at a time.
   • Worker Z is offline so unable to run any Builds.
5. Builds from Builders A and B will use the same BuildFactory, BF1.
6. Builder C will wait in the queue until either Worker X or Y become available.

BuildSets results are evaluated only after all Builds included in the BuildSet are finished. The results will be visible in the Buildbot Web Interface and also in CrossReference.