Closed Bug 765806 Opened 12 years ago Closed 12 years ago

Fix on-push build trigger by reverting local changes on the master

Categories

(Calendar :: Build Config, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ssitter, Assigned: Fallen)

References

()

Details

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'!
Sorry, the command that seems to fail is

'd:\\mozilla-build\\hg\\hg.exe' 'update' '--clean' '--repository' 'build' '--rev' 'mozilla-central'
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.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
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.
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.
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'
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.
Summary: Error during WINNT 5.2 comm-central lightning build: hg update abort: unknown revision 'mozilla' → Error during WINNT 5.2 comm-central lightning build: unrecognized SlaveCommand 'setMozillaBuildProperties'
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?
(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).
(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.
(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.
(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.
(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
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?
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.
Summary: Error during WINNT 5.2 comm-central lightning build: unrecognized SlaveCommand 'setMozillaBuildProperties' → Fix on-push build trigger by reverting local changes on the master
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?
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
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.
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.
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.
In case you have not noticed: after the last change all builds for all platforms are now broken.
Yes, sorry. Haven't had time to fix it. I've done some changes, it might work better now. Waiting for new builds.
Seems to be working, or am I seeing things?
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.
Win32 nightly builds are missing since 05-Jul-2012 again. 
No errors visible, build server seems to be not connected.
Restarted the machine, seems autologin is not working after all.
Should we close this bug? There exists more recent bugs to handle the current build errors.
Yes, I think this one can be closed
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.