Last Comment Bug 765806 - Fix on-push build trigger by reverting local changes on the master
: Fix on-push build trigger by reverting local changes on the master
Status: RESOLVED FIXED
:
Product: Calendar
Classification: Client Software
Component: Build Config (show other bugs)
: unspecified
: x86_64 Windows 7
: -- normal (vote)
: ---
Assigned To: Philipp Kewisch [:Fallen]
:
:
Mentors:
https://calendar-master.mozillalabs.c...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-18 10:06 PDT by Stefan Sitter
Modified: 2012-09-28 08:49 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Stefan Sitter 2012-06-18 10:06:56 PDT
WINNT 5.2 comm-central lightning build fails with

'd:\\mozilla-build\\hg\\hg.exe' 'clone' '--verbose' '--noupdate' 'http://hg.mozilla.org/comm-central' 'build'
...
abort: unknown revision 'mozilla'!
Comment 1 Stefan Sitter 2012-06-18 10:20:04 PDT
Sorry, the command that seems to fail is

'd:\\mozilla-build\\hg\\hg.exe' 'update' '--clean' '--repository' 'build' '--rev' 'mozilla-central'
Comment 2 Philipp Kewisch [:Fallen] 2012-06-19 03:25:15 PDT
This might be fixed, I'll have to wait until the next pushes. I tweaked the build config to not pass a branch anymore, but I'm not sure I got all instances.
Comment 3 Stefan Sitter 2012-06-19 10:29:55 PDT
Hard to say. Looking at https://calendar-master.mozillalabs.com/buildslaves/cal-vm-win32-1 it seems that no non-nightly build attempt was made in the last two days. Only nightly build attempts are listed.
Comment 4 Mark Banner (:standard8, limited time in Dec) 2012-06-19 11:27:45 PDT
I've just been able to trigger a new build for Windows on trunk. It has already passed the hg update step. Mac has just done the same as well, and they are now deep inside client.py, so hopefully they will run through.
Comment 5 Stefan Sitter 2012-06-19 13:21:33 PDT
https://calendar-master.mozillalabs.com/builders/WINNT%205.2%20comm-central%20lightning%20build/builds/1299

Looks like the compile step succeeded (yeah!) but afterwards the build failed with

buildslave.bot.UnknownCommand: unrecognized SlaveCommand 'setMozillaBuildProperties'
Comment 6 Mark Banner (:standard8, limited time in Dec) 2012-06-19 16:45:11 PDT
Unfortunately, fixing the hg step has also broken the triggering of builds on push to hg. I've left the triggering broken for now so that we just manually set off builds.

Tinderbox is also now starting to work, although obviously its quite red.
Comment 7 Stefan Sitter 2012-06-22 09:58:10 PDT
1) Any update or idea on the error message in Comment 5? wrong buildbot version? Is it possible to skip the xpi upload step to get to the nightly builds? I ask myself if the SeaMonkey build team has the same problems with the VM image we got from them.

2) comm-central shows similar error as in Bug 752202. can we workaround by e.g. temporary disable tests on the windows builders?

3) non-nightly builds are not working. according to Comment 6 triggering of builds on push to hg is broken. is there an bug for this problem?
Comment 8 Justin Wood (:Callek) 2012-06-22 10:06:39 PDT
(In reply to Stefan Sitter from comment #7)
> 1) Any update or idea on the error message in Comment 5? wrong buildbot
> version? Is it possible to skip the xpi upload step to get to the nightly
> builds? I ask myself if the SeaMonkey build team has the same problems with
> the VM image we got from them.

We do not, but we also do not have anything that runs that Step. iirc "Mozilla" no longer needed/wanted this magic in newer Buildbot code. SeaMonkey runs Buildbotmaster 0.8.2 and the VM has Buildbot Slave 0.8.4... I suspect you can get around this without the (missing) custom step.

> 2) comm-central shows similar error as in Bug 752202. can we workaround by
> e.g. temporary disable tests on the windows builders?

Yes that should get you past that error (I think).
Comment 9 Mark Banner (:standard8, limited time in Dec) 2012-06-22 10:36:32 PDT
(In reply to Justin Wood (:Callek) from comment #8)
> > 2) comm-central shows similar error as in Bug 752202. can we workaround by
> > e.g. temporary disable tests on the windows builders?
> 
> Yes that should get you past that error (I think).

Its probably better to see if we can shorten the object directory name. Otherwise we might run into issues with make check.

(In reply to Stefan Sitter from comment #7)
> 3) non-nightly builds are not working. according to Comment 6 triggering of
> builds on push to hg is broken. is there an bug for this problem?

Its all inter-related, lets not split it up too much and keep it in this bug.
Comment 10 Mark Banner (:standard8, limited time in Dec) 2012-06-22 11:49:18 PDT
(In reply to Mark Banner (:standard8) from comment #9)
> (In reply to Justin Wood (:Callek) from comment #8)
> > > 2) comm-central shows similar error as in Bug 752202. can we workaround by
> > > e.g. temporary disable tests on the windows builders?
> > 
> > Yes that should get you past that error (I think).
> 
> Its probably better to see if we can shorten the object directory name.
> Otherwise we might run into issues with make check.

I have a patch locally that I think will fix this, I'll push it over the weekend if I get time.
Comment 11 Mark Banner (:standard8, limited time in Dec) 2012-06-22 15:28:01 PDT
(In reply to Mark Banner (:standard8) from comment #10)
> (In reply to Mark Banner (:standard8) from comment #9)
> > (In reply to Justin Wood (:Callek) from comment #8)
> > > > 2) comm-central shows similar error as in Bug 752202. can we workaround by
> > > > e.g. temporary disable tests on the windows builders?
> > > 
> > > Yes that should get you past that error (I think).
> > 
> > Its probably better to see if we can shorten the object directory name.
> > Otherwise we might run into issues with make check.
> 
> I have a patch locally that I think will fix this, I'll push it over the
> weekend if I get time.

I've shortened the directory now, and the base directory of the nightly build is one character shorter than the Thunderbird one. So hopefully this will be good enough for now.
Comment 12 Mark Banner (:standard8, limited time in Dec) 2012-06-22 15:33:59 PDT
(In reply to Mark Banner (:standard8) from comment #11)
> I've shortened the directory now, and the base directory of the nightly
> build is one character shorter than the Thunderbird one. So hopefully this
> will be good enough for now.

FTR: http://hg.mozilla.org/build/buildbot-configs/rev/1b90701695d6
Comment 13 Stefan Sitter 2012-06-26 10:48:54 PDT
I don't know how but you managed to fix the unrecognized SlaveCommand 'setMozillaBuildProperties' error. Would it be useful to document the fix here in case someone else runs into the same problem?

Mark, do you want to keep this bug open for the "triggering of builds on push to hg is broken" problem?
Comment 14 Philipp Kewisch [:Fallen] 2012-06-27 04:57:00 PDT
Actually, we ended up downgrading the windows buildslave to 0.7.10p1, which still had the mozilla build properties step.

Lets keep it open for the builds on push, I just have to revert the changes I made locally on the master.
Comment 15 Philipp Kewisch [:Fallen] 2012-06-29 15:01:06 PDT
I have reverted the changes and reconfigured the master. Lets wait for a push or two (in the best case one on c-c and one on m-c) and then close this bug.

The only local changes are the directory length fix and using different boxes for certain builds.

Mark, do you want to push the directory length fix to the repo?
Comment 16 Stefan Sitter 2012-06-30 10:30:23 PDT
win32 and macosx lightning nightly failed again with a similar error as comment 0:

> d:\mozilla-build\hg\hg.EXE update --clean --repository
>   e:\builds\slave\cc-win32-nightly\build --rev comm-central
> abort: unknown revision 'comm'!

WINNT 5.2 comm-aurora lightning nightly:

> d:\mozilla-build\hg\hg.EXE update --clean --repository 
>   e:\builds\slave\ca-win32-nightly\build --rev releases/comm-aurora
> hg: parse error at 8: syntax error

WINNT 5.2 comm-central lightning build:
WINNT 5.2 comm-aurora lightning build:
> abort: destination 'e:\builds\slave\comm-aurora-win32\build' is not empty
> abort: destination 'e:\builds\slave\comm-central-win32\build' is not empty
Comment 17 Philipp Kewisch [:Fallen] 2012-06-30 13:50:49 PDT
WTF? So in that case all I can imagine is downgrading the buildbot even further. The current version is 0.7.10p1, I believe our linux slave uses 0.7.7. I'll check what the old windows machine is using, maybe I can just copy over the python bits from that.
Comment 18 Philipp Kewisch [:Fallen] 2012-06-30 23:51:37 PDT
Which doesn't really make sense since the master itself is also version 0.7.10p1. I guess I'll need to retry getting the bogus "comm" branch out of the dep builds and re-apply the master changes.
Comment 19 Philipp Kewisch [:Fallen] 2012-07-01 03:09:50 PDT
I re-applied the master changes (hopefully, didn't keep a backup since I didn't expect this), lets see what happens now. Afterwards the next step is figuring out how to get the branch out of the polled changes, or set it correctly.
Comment 20 Stefan Sitter 2012-07-02 12:40:11 PDT
In case you have not noticed: after the last change all builds for all platforms are now broken.
Comment 21 Philipp Kewisch [:Fallen] 2012-07-02 14:47:17 PDT
Yes, sorry. Haven't had time to fix it. I've done some changes, it might work better now. Waiting for new builds.
Comment 22 Philipp Kewisch [:Fallen] 2012-07-05 09:30:10 PDT
Seems to be working, or am I seeing things?
Comment 23 Stefan Sitter 2012-07-05 09:35:23 PDT
I see only nightly builds running on the server. I see neither normal builds that are triggered by hg pushes automatically nor unittest builds running the xpcshell test.
Comment 24 Stefan Sitter 2012-07-08 12:30:24 PDT
Win32 nightly builds are missing since 05-Jul-2012 again. 
No errors visible, build server seems to be not connected.
Comment 25 Philipp Kewisch [:Fallen] 2012-07-08 14:34:36 PDT
Restarted the machine, seems autologin is not working after all.
Comment 26 Stefan Sitter 2012-09-28 05:49:43 PDT
Should we close this bug? There exists more recent bugs to handle the current build errors.
Comment 27 Philipp Kewisch [:Fallen] 2012-09-28 08:49:14 PDT
Yes, I think this one can be closed

Note You need to log in before you can comment on or make changes to this bug.