Administration of our CI server

Our Continuous Integration server can be reached under http://saros-build.imp.fu-berlin.de/jenkins. You may look around and examine the artifacts and history of the various jobs without being logged in - this is part of our understanding of Saros being open source. Even as a developer, you'll mainly interact with Gerrit and just wait for Jenkins' responses as soon as you pushed a change for review. However, some more ambitious development tasks may require changes to our CI server configuration. If you find yourself in this position, this is the page you need to read and understand first.

How do I gain access?

In case you're a student and working on your thesis, speak to your adviser to determine whether it's really helpful (or necessary) for you to perform changes to the CI server configuration.

However, if you are an external developer, just contact the other developers on saros-devel@googlegroups.com. You will reach the right persons there and we will discuss both the necessity and the procedure of giving you access to the CI server.

What are the general rules?

Once you got access to the CI server, you are technically allowed to do whatever you want. But there are still some things we do not want to happen. The prevent this, we have the following rules:

1. Don't delete any jobs.
   If you think you discovered a superfluous job, bring up the topic on the developers' mailing list. Exception: You just created the job yourself (see rule no. 2).
   • Don't delete any builds.
     Every job configuration should have a policy when to discard old builds (e.g. by date or by number). This helps keeping the disk usage under control. But don't be too stingy: It's often quite nice to be able to compare a recent build to an older one, especially if something wrong. So don't manually delete any builds, especially failed and unstable ones. Sometimes you might think that a particular build may not be interesting - but don't decide for the other developers, because they might be very interested.
2. Make a copy of a job before you start working on it.
   Jenkins offers the possibility to create new jobs by copying an existing one. Make use of this feature and amend the configuration of the copy until you're satisfied. Exception: Only minor changes (of which you fully understand the effects) are allowed to be done directly in the original jobs.
3. Don't disturb the work of others.
   The copy-before-editing rule is a special case of this one. Further possible sources of disturbance include:
   • E-mail notifications
     Several jobs have an e-mail notification to inform developers about unstable or failed builds. Some changes are prone to produce some failing builds before succeeding. Please take care that these failures are not sent to saros-devel (e.g. by creating a copy and removing the e-mail notification from the post-build options).
   • Failed Gerrit builds
     Jenkins builds changes as soon as a new patch set has been pushed to Gerrit. Without Jenkins positive vote it is not possible to submit a patch. So failed, aborted, or unstable builds tend to be pretty annoying, especially when the failure has nothing to do with the patch itself but with the configuration of the job. You can use the Retrigger feature to manually (re-)start a once-failed build.
     If you manually trigger a build, all reviewers included in the corresponding patch will be notified. So leave an explanation who (you) and why (think first) re-triggered the build as a comment for the patch, especially when you accidentally triggered such a build.
4. Be careful about aborting a build.
   Although Jenkins offers the possibility to abort a build, use it with care. For instance, aborting a Gerrit job only makes sense if you run the same build again soon, otherwise Jenkins' negative/missing vote in Gerrit will preclude the submission.

Troubleshooting

Job "Test_STF"

Symptom: Normally, this job takes between 17 and 22 minutes to complete. Significantly larger times, like an hour or more, indicate lots of timeouts in the communication between saros-build and saros-eclipse1/2.

What to do: Check the network connectivity. Try to login from saros-build on saros-eclipse1. If this works, make sure IP traffic forwarding is enabled, e.g. by calling "ping google.com" from saros-eclipse1.