[Qa-jenkins-dev] pull request

[Hans-Christoph Steiner]

Holger Levsen:
> Hi,
> 
> taking this conversation from private to the public list… (after asking Hans 
> whether thats ok.)
> 
> On Dienstag, 9. Februar 2016, Hans-Christoph Steiner wrote:
>>> that said+done, I'm not 100% happy running this (=external script) as
>>> jenkins user on the host(s) so maybe I'll jail this away in schroot some
>>> day…
>>
>> External scripts will be run no matter what with this build job, 
> 
> yeah, we run external code all the time, so that's nothing new. (And for this 
> reason the design of jenkins.d.n is to not trust it for anything but QA…)
> 
>> here's
>> the chain of calls:
>>
>> 1. reproducible_setup_fdroid_build_environment.sh
>> 2. ./jenkins-build-makebuildserver
>> 3. ./makebuildserver
>> 4. vagrant
>> 5. chef
>>
>> ./jenkins-build-makebuildserver is run once a day on our jenkins, so
>> issues with it should hit us first.
> 
> nice
> 
>>
>> And in case you missed this on IRC:
>>
>>  normally in Jenkins that is $WORKSPACE
>> (05:26:18 PM) h01ger: whether you call/do it revert+fixing or fixing…
>> (05:26:37 PM) h01ger: WORKSPACE should be set, check the job output
>> (05:26:51 PM) h01ger: and inside that, there should be fdroidserver
>> (05:27:12 PM) ***h01ger goes afk from irc again
>> (05:27:15 PM) _hc: it is doing the clone right into WORKSPACE, which is
>> normal jenkins behavior:
>> (05:27:15 PM) _hc:  > git init
>> /srv/jenkins/pseudo-hosts/profitbricks-build3-amd64/workspace/reproducible_
>> setup_fdroid_build_environment_profitbricks3 # timeout=10
>> (05:27:21 PM) _hc:
>> https://jenkins.debian.net/job/reproducible_setup_fdroid_build_environment_
>> profitbricks3/lastBuild/console (05:27:33 PM) mapreri: h01ger: the point
>> is, jenkins check it out in jenkins.d.n, but the script run in pb3.
> 
> ah, "wow", I thought the jenkins slave handling would take care of doing the 
> checkout on the slaves… but I have just checked and indeed 
> /srv/jenkins/pseudo-hosts/ is totally empty on pb-build3 while it has 
> everyhint on jenkins itself. hmmpf.
> 
> My suggestion is to keep letting the job have a checkout of that git repo, so 
> commits to it will trigger a build, but do the git clone also inside the 
> script, so it will work on remote slave.
> 
> I suppose this lack of functionality is caused by using weasel ssh-slave-
> wrapper… (which gives us other features which I deem more important.)
> 
> I've now commited + deployed another attempt of fixing this. Triggering a job 
> run now…

Ok, we're back to where we were before with the fail on timeout.  My
guess is that its trying to use an old broken instance.  Can you delete
the old vagrant/VirtualBox setup?  Those both should now be totally
self-contained in the jenkins job, and wiped on each build.  That is
done like this:

rm -rf ~/.vagrant.d
rm -rf ~/VirtualBox\ VMs
rm -rf ~/.config/VirtualBox/

Just be sure nothing else is using vagrant or VirtualBox, since this
would delete all the settings and VMs!

If that fails, then we'll have to launch the VirtualBox GUI to see where
the failure is. It'll work over X11 forwarding.

.hc