884788 - Spidermonkey rootanalysis builds aren't force-clobbering correctly

Status: RESOLVED WORKSFORME

(Release Engineering :: General, defect)

Description

[Ed Morley [:emorley]]

Today we had a potential "needed clobber since Try was green and the inbound landing wasn't" failure (bug 883171).

However using the clobberer to force a clobber didn't seem to work.

The subsequent job didn't "TindeboxPrint: forced-clobber" and also from the configure/compile output (presuming I'm reading it correctly), it seems like the obj-dir wasn't empty:
https://tbpl.mozilla.org/php/getParsedLog.php?id=24329105&full=1&branch=mozilla-inbound

Output from the clobber build step:
{
+ export CLOBBERER_URL=http://clobberer.pvt.build.mozilla.org/index.php
+ CLOBBERER_URL=http://clobberer.pvt.build.mozilla.org/index.php
+ cd /builds/slave/m-in_l64-d_sm-rootanalysis-000/scripts/../..
+ python /builds/slave/m-in_l64-d_sm-rootanalysis-000/scripts/clobberer/clobberer.py -s scripts -s buildprops.json http://clobberer.pvt.build.mozilla.org/index.php mozilla-inbound 'Linux x86-64 mozilla-inbound leak test spidermonkey_mozilla-inbound-rootanalysis build' m-in_l64-d_sm-rootanalysis-000 bld-centos6-hp-007 http://buildbot-master61.srv.releng.use1.mozilla.com:8001/
Checking clobber URL: http://clobberer.pvt.build.mozilla.org/index.php?master=http%3A%2F%2Fbuildbot-master61.srv.releng.use1.mozilla.com%3A8001%2F&slave=bld-centos6-hp-007&builddir=m-in_l64-d_sm-rootanalysis-000&branch=mozilla-inbound&buildername=Linux+x86-64+mozilla-inbound+leak+test+spidermonkey_mozilla-inbound-rootanalysis+build
...
<snip>
...
m-in_l64-d_sm-rootanalysis-000:Our last clobber date:  None
m-in_l64-d_sm-rootanalysis-000:Server clobber date:    2013-06-19 07:13:05
...
<snip>
...
+ cd /builds/slave/m-in_l64-d_sm-rootanalysis-000/scripts/..
+ python /builds/slave/m-in_l64-d_sm-rootanalysis-000/scripts/buildfarm/maintenance/purge_builds.py -s 4 -n info -n 'rel-*' -n 'tb-rel-*' -n m-in_l64-d_sm-rootanalysis-000
}

Looking at clobberer.py, we intentionally don't clobber if 'Our last clobber date' is None (which is read from the 'last-clobber' file in the objdir) - so presume we're not updating this file correctly?

Comment 1

[Ed Morley [:emorley]]

(In reply to Ed Morley [:edmorley UTC+1] from comment #0)
> Looking at clobberer.py, we intentionally don't clobber if 'Our last clobber
> date' is None (which is read from the 'last-clobber' file in the objdir) -
> so presume we're not updating this file correctly?

Or else the objdir had already been clobbered (and I misread the configure/compile steps) but we not correctly outputting the tinderboxprint line.

Comment 2

[Chris AtLee [:catlee]]

I don't think clobberer.py prints out TinderboxPrint: forced-clobber. That is currently done by the buildbot clobber step: http://hg.mozilla.org/build/buildbotcustom/file/687de43bbf8d/steps/misc.py#l351

We should probably move this logic into clobberer.py, and mozharness's copy of clobberer.py

Comment 3

[Chris AtLee [:catlee]]

Is this still a problem? I checked some recent logs and do see TinderboxPrint statements now. I can't tell from the description if this bug is about not clobbering properly, or about not reporting that we were clobbering. If it's the latter, then I think that's fixed.

Comment 4

[Ed Morley [:emorley]]

This is so long ago I really don't know - let's just call this WFM