On Fri, Sep 20, 2013 at 09:43:06AM +0100, Frank Shearar wrote:

On 20 September 2013 04:02, David T. Lewis lewis@mail.msen.com wrote:

...

On Thu, Sep 19, 2013 at 10:27:11PM -0400, David T. Lewis wrote:

...

I am seeing console output like this:

http://build.squeak.org/job/CogVM/335/console

Construction ?? distance sur lfpdeb64 in workspace /home/tonyg/jenkins/workspace/CogVM

So how did a job that I set up to run on build.squeak.org end up getting executed on a remote machine in an inappropriate environment?

I am guessing that the job got assigned to the lfpdeb64 slave machine of Tony Garnock-Jones, but I cannot see how or why that happened. Any ideas?

Sorry to reply to my own question, but I think I see the problem. We have added slaves to the Jenkins configuration, and Jenkins attempts to assign jobs to available servers, so jobs that I had originally set up on the build.squeak.org master are now being assigned elsewhere. I need to configure the InterpreterVM and CogVM jobs to run only on the master, which is a configuration setting in Jenkins for each of these jobs.

To be specific, Jenkins will run a job on an "appropriate" slave, where "appropriate" means "the tags on the job match the tags on the slave". So if you need to run a job on a FreeBSD machine, set the "label expression" field to "freebsd".

For CogVM you could use "linux && 32bit", unless you specifically want to run the job on only build.squeak.org, in which case just leave the field the way you have it :)

I understand now. I have changed both jobs to force running on "master".

Both of these jobs generate VM source tarballs, but they also run a compile step to verify that the sources are reasonably sane (for example, a change in VMMaker that affects the code generator can easily cause a failure). The compile check requires various development libraries to be present on the system, so it is not appropriate to run this on an arbitrary slave.

Dave