-
Notifications
You must be signed in to change notification settings - Fork 32
NightlyBuilds
Nightly builds are performed on several different machines, with a variety of hardware, operating systems, configurations, and tests. At present, however, there are no nightly builds for ARM, Windows, or Common Larceny; those systems are built manually.
Collecting and reporting the results of those nightly builds became ad hoc (at best) when a couple of machines failed and our Trac site disappeared. Will is restructuring the process to create separate scripts for builds, tests, benchmarking, reporting, formatting, and publication. This will result in a process that does not depend on CDash (or similar software) but is capable of formatting results for publication via CDash.
Some of the machines that run nightly builds do not allow incoming SSH/SFTP, but can initiate outgoing SFTP connections. That motivates the following process.
- Machines run nightly builds, placing all log files in standard places.
- If a nightly build machine does not allow incoming SSH/SFTP, it must use outgoing SFTP to transfer its log files to a machine that accepts incoming SFTP.
- A formatting server uses SFTP to copy those log files to its local file system.
- The formatting server scrapes the log files to create a summary of what happened, and converts those summaries into static HTML and/or XML acceptable to CDash.
- The CDash format can be sent to a CDash server.
- A web server copies the log file directories and the formatted static HTML into its own file system.
The web server needs to know about the formatting server, but does not need to know anything about the log file directory structure or nightly build machines. The formatting server needs to understand the log file directory structure, and has to communicate directly with the machines that perform nightly builds. The machines that perform nightly builds do not need to know anything so long as they accept incoming SFTP from the formatting server.
We need scripts for
- building every configuration of Larceny we still want to support
- IAssassin (IA32 and Sassy, for Linux, MacOS X, and Windows)
- ARM
- PetitNasm (maybe)
- Petit Larceny (for Linux x86 and MacOS X PowerPC)
- Common Larceny (if we want to continue to support it)
- running every set of tests and benchmarks we want to run on a nightly basis
- basic tests (test/Lib, test/Compiler)
- CLisp number tests
- trigtests
- Racket R6RS tests
- R7RS tests (Chibi)
- R7RS tests (Larceny)
- SRFI tests
- copying build/test/benchmark XML and log files to the file server
- XML files (and the most interesting search keys for summaries) are:
cdash-update-sub.xml
cdash-config-sub.xml
-
cdash-build-sub.xml
" Name="
"<StartDateTime>"
"larceny.heap, built on "
"<EndDateTime>"
"<ElapsedMinutes>"
-
cdash-tests-sub.xml
"* FAILURE *"
" failure(s) detected in the group "
-
cdash-bench-sub.xml
"<ElapsedMinutes>"
- log files are:
-
git.log
(currentlyupdate.log
) build.log
-
buildR7RS.log
(currently part ofbuild.log
) -
basic.log
(currentlytests.log
and cluttered) -
racketR6RS.log
(currently not present, not run) -
chibiR7RS.log
(currently not present, not run) -
larcenyR7RS.log
(currently not present, not run) -
clispNumbers.log
(currently not present, not run) -
trigTest.log
(currently not present, not run) -
srfi.log
(currently not present, not run) -
benchmarks.log
(currentlytemp.log
)
-
- configuration directories are:
-
linux86native
(currently Ubuntu 12.04) -
linux86petit
(currently Ubuntu 12.04) linux86native-regional
linux86petit-regional
linux86native-flat1
linux86petit-flat1
-
linux86native2
(currently Ubuntu 14.04) -
linux86petit2
(currently Ubuntu 14.04) -
macosx
(currently 10.4.11) -
macosx2
(currently 10.8.5) macosx3
windowsXP
windows
commonLarceny
linuxARM
linuxARMpetit
-
- XML files (and the most interesting search keys for summaries) are:
- pulling those directories of log files from the nightly build machines
- submitting the XML files to a CDash server (optional)
- scraping the XML and log files
- formatting the summary information into HTML
- pulling the log file directories and formatted summaries into the web server
-
crontab -l
lists the current user's crontab, andcrontab -e
edits a copy of the current user's crontab file and installs the copy as their crontab when editing is complete. (Also the only way to remove all lines from a crontab iscrontab -r
, according to thecrontab
man page.) - Each nightly build uses git or svn to clone/checkout a copy of the source code.
- If a machine does not accept the GitHub certificate, the script will block. To fix that, do a manual clone/checkout on the machine in question, indicating permanent acceptance of the certificate.
- In the past, we have performed nightly builds on Windows and PowerPC/MacOSX machines.
- The Windows builds were discontinued long ago because any infinite loop or other problem that occurred during the build could be resolved only by sitting in front of the physical machine.
- The PowerPC builds have been discontinued because we don't have a PowerPC machine that's always turned on; PowerPC builds can still be performed manually.
- Each autobuild machine has a copy of a
nightly-build
script that drives the autobuild process each night. (Warning: some of the details below are no longer true.)- The usual way that it works is that each autobuild host has several symbolic links to that same script, but with specially chosen names for the link's name.
- (Yes, this is a strange way to do things. But it does make the purpose of each link self-evident, once they are set up accordingly.)
- The parameters for the build (whether it should use Larceny or MzScheme as the host, whether it is a Native or Petit build, etc) are encoded in the name of the link.
- Then, each autobuild host has a single script (which Felix usually named
checkout-svn-mail
; for the new process, Will is naming itnightly-build-submit
) that is run every night, which:- runs each of the linked scripts
- places the log files in a standard place so the formatting server can find them
- The usual way that it works is that each autobuild host has several symbolic links to that same script, but with specially chosen names for the link's name.