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

RESOLVED FIXED

Status

Calendar
Build Config
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Stefan Sitter, Assigned: Fallen)

Tracking

Details

(URL)

(Reporter)

Description

5 years ago
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'!
(Reporter)

Comment 1

5 years ago
Sorry, the command that seems to fail is

'd:\\mozilla-build\\hg\\hg.exe' 'update' '--clean' '--repository' 'build' '--rev' 'mozilla-central'
(Assignee)

Comment 2

5 years ago
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
(Reporter)

Comment 3

5 years ago
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.
(Reporter)

Comment 5

5 years ago
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.
(Assignee)

Updated

5 years ago
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'
(Reporter)

Comment 7

5 years ago
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
(Reporter)

Comment 13

5 years ago
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?
(Assignee)

Comment 14

5 years ago
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
(Assignee)

Comment 15

5 years ago
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?
(Reporter)

Comment 16

5 years ago
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
(Assignee)

Comment 17

5 years ago
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.
(Assignee)

Comment 18

5 years ago
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.
(Assignee)

Comment 19

5 years ago
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.
(Reporter)

Comment 20

5 years ago
In case you have not noticed: after the last change all builds for all platforms are now broken.
(Assignee)

Comment 21

5 years ago
Yes, sorry. Haven't had time to fix it. I've done some changes, it might work better now. Waiting for new builds.
(Assignee)

Comment 22

5 years ago
Seems to be working, or am I seeing things?
(Reporter)

Comment 23

5 years ago
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.
(Reporter)

Comment 24

5 years ago
Win32 nightly builds are missing since 05-Jul-2012 again. 
No errors visible, build server seems to be not connected.
(Assignee)

Comment 25

5 years ago
Restarted the machine, seems autologin is not working after all.
(Reporter)

Comment 26

5 years ago
Should we close this bug? There exists more recent bugs to handle the current build errors.
(Assignee)

Comment 27

5 years ago
Yes, I think this one can be closed
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.