I need a win32 unittest slave connected to: dev-master1.build.mozilla.org:8951 Judging by the builder list (I hope I've set up the master correctly), I need one from the "t-w732-ix-" pool.

Note that all I really need is some unittest machine connected to that master. I don't need to access the machine itself, so this doesn't technically need to be a loan.

Assigning to jlund, aka build duty the week of March 3rd.

Hi Fallen, I have t-w732-ix-001 for you ready to go but it seems like your master is not on slavealloc. I can see: dev-master1.build.mozilla.org:8950 but not 8951 Ahh, wait, I can see Bug 978237 in this bug's dependent list. Let me look into that first.

see 978237 for details. I am blocked on adding things to slavealloc db. I will find someone to do this for you tomorrow if this is not resolved.

OK I have t-w732-ix-001 assigned to your newly added test master via slavealloc. It look's like it is already taking jobs: http://dev-master1.srv.releng.scl3.mozilla.com:8951/buildslaves/t-w732-ix-001 Although I'm guessing you didn't create these jetpack jobs. Ask around #releng if you don't know how to stop other jobs from getting pended. I don't think you can just remove the 'scheduler' or 'change' values from buildbot master.cfg as you still need to fire sendchanges. I am assigning this bug to you. when you are done with the slave forever, please assign it to nobody and mark as resolved. Note: this was a production machine so I had to put it in the dev/pp, preprod-testing env pool. We need to put it back in the production pool again when this is resolved.

Hal pointed out this might now work. I may have given the slave the staging password (the password Fallen's master uses) but it will still have production things like keys/secrets. This may cause spurious results when trying to upload to staging servers with production keys. Coop do you know off your head if I should worry about anything here for a production test slave connected to a staging master? See comment 5 for context. Sorry Fallen but I am going to disable and unlock this slave from you until I get a clear idea of the consequences. Thank you for your patients.

As a side note. What is the motive for this? If you are trying to test sendchanges from one of your builders, they should be sent to the stage master. If you are needing to test out a 'test build' and play around with it, ignore this comment.

I don't know where those jobs are coming from, I don't think I've set up my build master to sendchange to the tests master. The only jobs it should be getting are comm-* jobs. I want to have packaged tests run for Lightning, which requires packaging the extension with the tests, because they are not in the usual Thunderbird packages that are downloaded. This requires a 1-line buildbot change and a few makefile changes.

(In reply to Jordan Lund (:jlund) from comment #6) > Coop do you know off your head if I should worry about anything here for a > production test slave connected to a staging master? See comment 5 for > context. Test slaves should have no keys, so we should be fine here. We only need to worry about keys for build/try machines. If the slave refuses to connect to the staging master, it's pretty simple to check the db to see what password the master is expecting and then update BuildSlaves.py on the master to match.

great thanks. I re-locked it to fallen's test master and rebooted it. It should connect again. Fallen, if you can remember, when you close this bug (you're done with the slave), can you mention that this slave should be put back on production pool/env via slavealloc. Thanks and good luck!

(In reply to Philipp Kewisch [:Fallen] from comment #8) > I don't know where those jobs are coming from, I don't think I've set up my > build master to sendchange to the tests master. The only jobs it should be > getting are comm-* jobs. > > I want to have packaged tests run for Lightning, which requires packaging > the extension with the tests, because they are not in the usual Thunderbird > packages that are downloaded. This requires a 1-line buildbot change and a > few makefile changes. OK cool, you can ignore my comment then. you can force/take jobs as much as you like with this setup. If you are getting jobs and you don't want them (like maybe jetpack), you can remove them. If you don't know how, ping someone in #releng :)

I am done with this slave. Please see comment 10, which notes this slave should be put back on production pool/env via slavealloc.

I'm returning this to the production pool now...