[Buildbot-devel] 0.8.8 code executed in master instead of slave?

[Julia S.S.]

I think I have not explained myself properly
I have different builds with same config, linked to their slaves.
Eg. i have builds named package-win, package-lin32, package-lin64,
package-macos builds, linked to slave-win, slave-lin32 etc respectively.
They all execute same build steps and they are all triggered at the same
time when a push to release/* is performed

S3 step has a start method such as:

 def start(self):
        path = self._get_binary_path()
        upload_name = self._get_upload_name()
        folder = self.getProperty('branch')
        conn = boto.connect_s3(AWS_ACCESS_KEY_ID, AWS_KEY)
        bucket = conn.get_bucket('binaries')
        k = bucket.new_key('%s/%s' % (folder, upload_name))
        k.set_contents_from_filename(path)
        self.finished(SUCCESS)

upload name is correctly generated, as I get different binaries with
different names, problem is they are all the same which, can only mean that
it's being uploaded from the master-host


On Tue, Jul 23, 2013 at 2:55 PM, Dustin J. Mitchell <dustin at v.igoro.us>wrote:

> On Tue, Jul 23, 2013 at 7:56 AM, Julia S.S. <hithwen at gmail.com> wrote:
> > However, since the update, it seems artifacts are always uploaded from
> the
> > master (which has a local slave running, so the directory exists). Also I
> > have another custom buildstep that executes a commnad that's inferred
> from
> > slave os.platform (removing pyc files, command its not the same in unix
> and
> > win :p). That also stopped working and now tries to execute find * on
> > windows
>
> None of that has changed.  My guess is that you have slaves running on
> both hosts, and were just lucky enough to have jobs run on the correct
> host before - selection of a slave from the set of slaves configured
> for a builder is random.  In 0.8.8, you've been less lucky.
>
> Dustin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20130723/b543edf9/attachment.html>