Testing if a jenkins container finished booting

When running Jenkins as a docker container for test purposes, it is necessary to verify the Jenkins master is fully functional before running the first test cases.
The http interface can be tested with a call to the API such as

curl --silent http://jenkins.host/api/json

It will first fail with Connection reset by peer, then with 503 Server Error: Service Unavailable and return a JSON output after a few seconds.
The Jenkins CLI can be tested by sending the help command.

$ wget -O /tmp/jenkins-cli.jar http://jenkins.host/jnlpJars/jenkins-cli.jar
$ java -jar /tmp/jenkins-cli.jar -s http://jenkins.host help

and it will use port 50000 to connect to the jenkins master. It will first fail with an error such as

SEVERE: I/O error in channel Chunked connection to http://jenkins.host/cli
java.io.StreamCorruptedException: invalid stream header: 0A0A0A0A

meaning the connection to port 50000 failed (the error message is misleading).
It will eventually succeed with

   add-job-to-view
    Adds jobs to view.
  build
...

If security is disabled (which is the default when running the container), a call to the CLI will succeed despite the following error message.

SEVERE: I/O error in channel CLI connection to http://jenkins.host
java.io.IOException: Unexpected termination of the channel

gerrit with jenkins : installation and configuration

The review and project management for Git based projects is installed on a virgin Debian GNU/Linux wheezy. Developers of l2mesh must submit patchs to the git repository to gerrit:

$ git review
remote: Resolving deltas: 100% (1/1)
remote: Processing changes: new: 1, done
To ssh://loic@gerrit.the.re:29418/l2mesh
 * [new branch]      HEAD -> refs/publish/master/master

Gerrit is bound to jenkins : it will run tests on the patch to be reviewed and let gerrit know if it succeeds. If a developer reviews the patch positively, it can be merged into the repository.


Continue reading “gerrit with jenkins : installation and configuration”

realistic puppet tests with jenkins and OpenStack (part 1/2)

A git repository containing a puppet module is bound to a jenkins project. When the repository changes, jenkins boots a virgin puppetmaster OpenStack instance in a dedicated tenant. It runs the run-jenkins-test-in-openstack.sh script in the puppetmaster instance. In addition to the puppet unit tests, the script will launch realistic tests by launching OpenStack instances and checking their state. The checks are done with nagios which can also be used in a production environment to continuously monitor the deployment.
Continue reading “realistic puppet tests with jenkins and OpenStack (part 1/2)”