canonical-ci-engineering team mailing list archive

[Vincent Ladeuil <vila+ci@xxxxxxxxxxxxx>]

Hi,

I've discussed that with jamespage and came up with the following
workaround:

   modified      debian/jenkins-slave.upstart
                                                                        

=== modified file 'debian/jenkins-slave.upstart'
--- debian/jenkins-slave.upstart	2013-02-17 17:11:13 +0000
+++ debian/jenkins-slave.upstart	2013-12-09 10:29:01 +0000
@@ -17,3 +17,6 @@
     exec start-stop-daemon --start -c $JENKINS_USER --exec $JAVA --name jenkins-slave \
         -- $JAVA_ARGS -jar $JENKINS_RUN/slave.jar $JENKINS_ARGS 
 end script
+
+# respawn if the slave crash
+respawn


I've deployed that on jatayu by adding 'respawn' to
/etc/init/jenkins-slave.conf so daily-release-executor should now
restart automatically (I've restarted the jenkins-slave service).

....


And then I noticed that per my own documented instructions at
https://wiki.canonical.com/UbuntuEngineering/CI/Playbook/q-jenkins#daily-release-executor
(wanting to update them...) that this is not the Right Thing :-/

First, patching /etc/init/jenkins-slave.conf will cause issues when
upgrading to a new version. This can/should be fixed by proposing that
upstream though.

Second, we use /usr/local/bin/start-jenkins-slaves which ignores the
upstart jobs :-/

I also realized then that we rely on start-jenkins-slaves to start
multiple slaves on jatayu... daily-release-executor indeed but also the
acer-veriton-0[123] slaves via /etc/default/jenkins-slave.

Feedback welcome first and then I'll probably revert that change until
we figure a better solution for which I'll file some asana 'Post 1SS' or
'CI Vanguard' task ;)

    Vincent