Explanation

If you do not already know how to read the pikefarm pages, they might seem a bit cryptic. Let us try to straighten out the question marks, starting with an overview of the system; what it does, what information it conveys and how it supports the Pike developers in improving Pike.

Pikefarm builds the most recent versions of Pike from GIT, on many different machines, hardware architectures and operating systems. When something changes in Pike, a new source distribution is made for the clients participating in the farm. They fetch it, compile it and, when successful, run the Pike testsuite on the result. Then they send back some log files with valuable feedback to the developers. Some post-processing later, a status blob appears in the matrix, indicating the level of success for the completed build.

The rows of the table corresponds to different build machines, and the columns represents the results of different builds, the most recent one on the far right. For each build client (row), we see what operating system and hardware architeture it compiled for, and some also list a specific test profile used.

The date/time stamps in the header of each column is the checkout time (in universal time) used for that build.

Okay, there already is a legend explaining the basics of the colorful check marks, but there is a bit more to say than what meets the eye here too. First, all colourful check marks are clickable and brings you to an in-depth view of the result reported by the client that compiled the build. That page is a topic of its own, though, so let's move on.

A green check mark means that the client built this Pike successfully, and ran the full test suite (about 170,000 tests in all at the time of writing this, and growing steadily) without a single fault.

A yellow check mark also means that the client built that Pike successfully, but that it failed on one or more tests in the testsuite; more details about what went wrong can be found in the verify log. Common causes are various kinds of resource starvation on the build machine; not enough memory, process table full, or even some operating system bug that was detected by the test suite (yes, the Pike test suite has a handful of tests designed to find such bugs to avoid debugging problems invented elsewhere).

A red check mark signifies that the client failed to build Pike for some reason (for obvious reasons, it did not run the test suite). Like in the case with the yellow check mark, this does not necessarily indicate that the source package was at fault; it might be due to a client configuration error, of some sort. This time too, reading the returned log files, the make log in particular, is key to understanding what went wrong.

Finally, the grey check marks signify all other conditions. Most commonly, the client never touched that build; perhaps because it was already busy with a previous build, perhaps because it was set up not to build more than once a day (or however often the owner of the machine prefers). Occasionally, when we have been busy working on Xenofarm (the build framework), some build results have even been lost or showed up late, also meaning gray check marks. Hence, when a client has managed to assemble a severely broken result package, it might escape the check mark radar.