openMSX running penguin logo openMSX is an open source emulator for the MSX home computer system, with high accuracy and many features for debugging MSX software. They use SoftFab to automate their builds and tests for several host platforms.

Below we will highlight some interesting pipelines used by openMSX and finally also show the full execution graph.

A linear pipeline

Most testing—both in SoftFab and on developer machines—will happen on version control (Git in this case) work areas. But when a release is made, it includes an official source package from which openMSX can be built.

To make sure the source package is complete, the release process document dictates that release binaries will be built from the source package instead of directly from Git. This has caught problems with the source package (mainly missing files) in the past.

However, it is better to discover such problems when they are introduced instead of when trying to get a release out. Therefore the following build pipeline was set up:

linear build pipeline
A linear build pipeline

This takes the source from Git, creates the source package, then unpacks the source package and builds the resulting source directory.

A non-linear pipeline

penguin holding a catapult openMSX has an optional launcher named Catapult, which is developed in a separate Git repository. Since most Windows users prefer GUIs to the command line, for the Windows releases of openMSX the emulator itself is bundled with Catapult.

In the graph below, you can see the part of the pipeline that builds openMSX and the part that builds Catapult joining in the task that creates the Windows binary package, since that package contains both openMSX and Catapult.

non-linear pipeline
A non-linear pipeline

The Execution Graph

The pipelines highlighted above do not exist in isolation. For example the update_openmsx_work_area task that configures a Git work area to contain a specific source revision is the exact same task in both pipelines.

Since pipelines can share tasks, we define tasks and products once and let each pipeline reference a subset of those. This means that if a task changes, it only needs to be updated in one place and all pipelines using that task will automatically use the updated definition.

All defined tasks and products together form the execution graph. The full graph of the openMSX SoftFab is depicted below. Try to spot the pipelines we described earlier in the graph!

complete execution graph
The execution graph of the openMSX factory

Quick reference:

  • You can visit the live openMSX SoftFab to see it in action and view the latest version of their execution graph.
  • Page Up