For example: validator1-linux-x86-head, freebsd-amd64-stable.
If the builder's name is prefixed with validator$n then it does not upload files, it produces logs only by building GHC and running the validate command on it, hence the name. Its purpose is just to check if everything works okay on the given configuration. It is mostly used on platforms (such as Linux) where official nightly builds are offered in many other fashions, so the builder infrastructure does not attempt to reproduce this functionality. However, it was judged that is still useful to test the build on various non-standard configurations. Notice the $n at the end: this is just an ever-increasing natural number to make the names unique.
If the builder's name does not have the "validator" prefix, the builder attempts to create a daily snapshot for the given platform, which may be accessed through the builder sub-page, see below. Its purpose is to check if GHC builds on the given platform (and architecture) and provide publicly-accessible development snapshots every time when the build succeeds.
Note that the name of the architecture may vary by platform. That is, the IA32 architecture is often called x86 and sometimes it is called i386, but they are essentially the same. The same applies to the AMD64, which is either called x86_64 or amd64.
Finally, the name of the GHC development branches are a bit different from the branches in the git repository. Though, the mapping is trivial: head refers to the master branch, while stable refers to the latest ghc-X.Y branch.
Results / Colors
Each build has a result, which is both marked by a distinct color and a brief name for the output. Such as:
Failure, red: One of the scheduled commands returned a non-zero exit
commands, hence the build process was stopped. This may refer to configuration or a
build failure, check the build page for the details.
Incomplete, yellow: The builder client was not able to run all the specified
commands to their completion. That is, the build process was somehow interrupted during
the build. It is recommended to check each of the steps to see where it was stopped.
Success, green: Everything happened as expected, that is, the builder client
was able to run all the scheduled commands and none of them has returned a non-zero exit
status. They can be ignored, however, this does not mean that the given build may have
not any problems.
The builder summary pages store information on every build, however, from the main page, only the top 10 builds are shown for each of the builders. In order to see the older builds, they can be individually accessed at the builder's sub-page. It has the URL of the following format, but they can be also accessed from the main page:
where $builder is the name of the builder by the conventions described above. This page contains the directory of all builds were ever collected for the builder in question.
Note that the entries on this page are in the following format:
$n: $result, $date $time UTC
where $n is the serial number of the build, $result is the result of the build (see above for explanation), $date and $time is date and time when the build was done. Following those links will lead to the build pages:
On those build pages, one can see the scheduled steps and their results. Such pages start with a header, which is of the following format:
$builder ($info), build $n, $result
where $builder is the name of the builder (per the previously introduced conventions), $info is the longer description of the builder, often containing the name of the maintainer, $n is the serial number of the build, and $result is the overall result of the build.
Steps with Their Results
Each step has a serial number and a brief explanation of its purpose, such as:
1: git clone2: create mk/build.mk3: get subrepos4: repo versions5: touching clean-check files6: setting version date7: booting8: configuring9: creating check-remove-before10: compiling[...]
Each of the steps are colored by the previously discussed conventions. That is, they are green, if that step did not have any problems, red, if something went wrong during the execution, and yellow, if the execution of the command was interrupted. This way, one could easily spot where the whole build failed. The page always includes a final result after the steps, which may be Success, Incomplete or Failure.
Depending on the configuration, uploads can be also linked to the build page. This is because some of the step may produce an output that is recorded by (that is, uploaded to) the central server. With this method, it is possible to save the results of the builds and make them available for downloading later.
where all the file names are hyperlinked. As mentioned earlier, validators do not have such sections.
Some of the steps are configured to inline their outputs in the build page to show some useful information about the actual status of the build. One of them, for example, is the testsuite summary, which may be of interest. Note that although such output may indicate test failures, the builder client will not mark them as failures as the error code of the corresponding command was zero. That is why one should be careful with interpreting the results of the builds.
Note that each of the steps are hyperlinked, which means they have links to contain further information on the details. Such sub-pages can be also individually accessed as:
where $program is the program to execute, $arguments is the arguments for the $program, specified as a standard Haskell list, $subdirectory is the directory where the $program was executed, relative to the root of the builder working directory, $start_time and $end_time mark the start and end times for the given command, respectively.
Note that the $result field has all the output of the executed program, marked down with colors, where red lines refer to the output of the subcommands. Warning: some of the pages may be huge due to the large number of recorded output lines. Opening them may take some time.
Finally, the $error_code can be either ExitSuccess, which implies that the step was okay, therefore marked as green, or ExitFailure $n, which implies a red color and therefore a failed step. The builder is instructed to stop once a failed step is encountered.
Upon receiving the build results, the central server -- if instructed -- also forwards them to the
ghc-builds mailing list. The mail contains a brief overview of the build results and links to the build page. In case of failures, the last couple of lines of the failing command are also included.