Table of Contents
This chapter describes how to run a BuildServer. It assumes you have installed the BuildServer software as described in Chapter 6, Installing the BuildServer .
![[Note]](note.png) | Note |
|---|---|
The build servers connect securely to the Submit Server to get submissions to build. In order to this, the unsigned security certificate associated with the submit server needs to be installed in the JVM that will run the build server. See Section 2.4.3 "Configuring SSL" of the Submit Server installation manual for more details. (If you are running the build server on the same host as the submit server, and you have already installed the certificate during the Submit Server installation process, then you can ignore this note.) |
A build server is usually run as a daemon process running in the background. It probes the associated SubmitServer to see if any submissions need to be built -- if this is the case, it downloads and builds these submissions. A Build Server can also be started from the command line to download and build a submission from the submit server, or to build a submission that is available offline. Starting the Build Server from the command line is often useful for debugging the Build Server behavior, because this arrangement prints out all its output to stdout.
To run the build server as a daemon process, a cron job is set up to periodically check that the server is still running. This ensures that if the server crashes, it is restarted. However, this feature can be bothersome if an administrator wants to kill the build server since it will be restarted within 5 minutes unless the cron script is changed. For maximum flexibility, the Build Server distribution includes a "cron-set" script that influences the behavior of the cron job.
Enable cron processes using the "cron-set" script. From the BuildServer directory, run:
scripts/cron-set -c CRONTAB.sh onThis command modifies the CRONTAB.sh script to ensure that it periodically checks to ensure that the build servers are running.
Run
./CRONTAB.sh. This starts the build servers created during the installation process. You can check for the existence of these processes by using the 'ps' command to look for new java processes.You can also login to the Submit Server, go to the SuperUser page, and click "BuildServerStaus" on the bread crumb. This should indicate that the Build Servers have recently contacted the Submit Server.
Disable cron processes using the "cron-set" script. From the BuildServer directory, run:
scripts/cron-set -c CRONTAB.sh offThis command modifies the CRONTAB.sh script to ensure that it does NOT restart the build server.
Run
./killall. This stops all the build servers created during the installation process.
Running the build server from the command line is often useful for debugging purposes. To run a single build server from the command line, first change directory (cd) into the build server directory that corresponds to the build server you wish to run. e.g.
cd bs1.ourserver.ourschool.eduUse the runBuildServer script which has the following usage:
Usage: ./runBuildServer <config file> [ once ]The config file is the "config.properties" file in the current directory. Adding the literal
onceto the command instructs the build server to shut down after it has downloaded and built a single submission from the Submit Server.
![[Warning]](warning.png) | Warning |
|---|---|
The build server working directories (bs1.*, bs2.* etc) are used to
store submission and test-setup information retrieved from the submit
server, and other temporary information needed during the testing
process. Therefore, you should not execute a build server that is in
the process of testing a submission because this will interfere with
the active testing process. Usually, the
runBuildServer
script is used when no build servers are active (i.e. all were shut
down with the
killall
script) or in a seperate build server installation.
|
It is also possible to run a build server offline on a particular submission. To do this, you will need a copy of the submission to be tested, and the associated test-setup. (Both can be downloaded from the Submit Server. See Chapter 10, Projects for more info about these two files.)
Set the BUILDSERVER_ROOT environment variable to point to the 'BuildServer/' directory (i.e. the main directory that contains the 'scripts', 'bin' and build.xml)
e.g.
export BUILDSERVER_ROOT=$HOME/buildServer/BuildServerCreate a new directory that will be used temporarily for the offline testing. You can create this directory anywhere except in any of the existing build server working directories (i.e. the ones named bs1.*, bs2.* etc.). Using any of these directories may create a conflict with any existing (and running) build servers.
Copy the zip files representing the submission to be tested, and its associated test-setup into the new directory. Both can be downloaded from the Submit Server.
The testSubmission.sh script in the 'BuildServer/scripts' directory will dynamically create a build server, run it once on the two zip files, and then shut it down. Example Usage:
$BUILDSERVER_ROOT/scripts/testSubmission.sh submission.zip test-setup.zipThis sends the build server output to stdout so you may want to pipe the output into a textfile so you can review it later. You may also want to add testSubmission.sh to your path if this is a task you perform often.