For questions or problems : Powertac Developer List

The use of the continuous integration tool Jenkins as a deployer and executer of Powertac games came as an idea within our group that turned out to be a great one. It saved a lot of time and simplified the problem greatly.

You need to have Apache Tomcat installed and working. These instructions were tested with 7.0.37.
Download the latest version of Jenkins, and deploy it in Tomcat. For setting up Tomcat, see Step 3

You can deploy wars via Tomcats manager interface : http://localhost:8080/manager/html, under 'Deploy', 'WAR file to deploy'.
A script in the install-dir of powertac-tournament-scheduler, install-jenkins.sh, does the download and deploy from the command line.

To learn more about Jenkins, visit its webpage: Jenkins

• Node and Label parameter plugin
• Throttle Concurrent Builds Plugin

We also need to add a multi-project throttle category : click on "Manage Jenkins", "Configure System".
Then under "Throttle Concurrent Builds", add :

• Category Name = game-server
• Maximum Total Concurrent Builds = 0
• Maximum Concurrent Builds Per Node = 1

There's a script to install all 4 jobs needed for the TS to function.
For this, you need to add an API token for Jenkins:

1. Click your name (upper-right corner).
2. Click Configure (left-side menu).
3. Use "Add new Token" button to generate a new one.

Remember this token, as it can not be viewed afterwards, and it is needed for the tournament properties.
Run the script once the HOST, USER and TOKEN are set:

$ ./configure-jenkins.sh

Navigate to http://{apache-tomcat-url}:8080/jenkins/ and ensure that 4 new jobs were created, called "start-sim-server", "start-boot-server", "abort-server-instance" and "kill-server-instance".

The reason of using Jenkins' slave is there is no the need of having a Jenkins master server (a Jenkins installation) for every machine we want to deploy a competition. A Jenkins' slave can be thought as a "thread", which takes its own configuration, and can be deployed to a machine in other to perform a job. Using slaves allow the remote deployment of jobs, which can be performed in a different machine other than the "main" one where the central Jenkins server is installed. Another advantage of slaves is its setup simplicity, and it also can stay "online", waiting for another job to be deployed. Finally, there is not the need to create a different job for each slave: The slave can be reconfigured, and redeployed to the target machine. For example, in your group's simulation, we have a central Jenkins server that has multiple jobs. Each job has a competition configuration, so it allows us to run multiple competitions at the same time. Each job is assigned to a machine, and that job is deployed through a slave.

To set up a new Jenkins' slave (you need to log in if your Jenkins install requires a user/password):

• In the main Jenkins tab go to "Manage Jenkins" (on the left) -> Manage Nodes -> New Node.
• Give the slave a name and select the option "Dumb Slave".
• "# of executors" must be set to 2.
• "Remote FS root" is the base directory for Jenkins files.
• "Labels" must be set to 'machine'.
• "Usage" must be set to 'Utilize this slave as much as possible'.
• "Launch method" must be set to 'Launch slave agents on Unix machines via SSH'.
• "Host" must be set the URL of the machine in which that slave will execute in.
• In order to configure, give it the private key file instead of your username / password for secure sake.
• "Availability" must be set to 'Keep this slave on-line as much as possible'.

You are done, and you have a slave ready to run competitions.

If the machine that hosts the slave isn't dedicated to running boots and sims, the creation of a local repo is advisable. Maven uses ~/.m2 by default, but this is used by all maven processes run by this user. This means that interaction with other processes cannot be ruled out, resulting in undefined behaviour. Somewhere on your machine, create a directory that will be used by maven as the local repo for each competition. This location will be referenced to maven during the mvn exec phase, described in the next topic. I advice you to create a maven repository for each machine where the slave will run a job. The reason why is because each job may have a different configuration, so there may have different results. By doing so, you keep things separated and organized.
This repo would have to be added to the maven-commands in start-boot-server and start-sim-server.
Find the lines with "CMD="$MVN_CMD -U -Pcli" in the command under Build, and add at the end :

-Dmaven.repo.local=LOCATION_OF_YOUR_LOCAL_REPO