Ticket #837 (new undecided)

Opened 4 months ago

Last modified 2 weeks ago

When doStepIf skips a step, finished() is called without start()

Reported by: gward Owned by:
Priority: major Milestone: 0.8.3
Version: 0.7.11 Keywords: tests
Cc: ccooper@…

Description

I have a custom build step that looks something like this:

class MyStep(ShellCommand):
    def start(self):
        ShellCommand.start(self)
        self.__privatedata = ...

    def finished(self, results):
        self.__privatedata.something()
        ...

This worked fine under 0.7.9 for a year or so. In particular, it was safe for finished() to assume that self.__privatedata was set, because start() was always called. But I recently had to upgrade to use doStepIf. (Nice feature: thanks to whoever implemented it!)

Now the assumption behind my finished() is no longer correct. If a step is skipped because doStepIf returns false, start() is never called, but finished() is. So my step fails with AttributeError.

I've worked around it with try/except, but this seems bogus. It would be nice if we could go back to guaranteeing that start() is called, but I can see how that might be difficult. I would be perfectly happy to have a method in BuildStep that *is* guaranteed to be called before the step runs, regardless of whether start() is called. Then I can add private data attributes safely.

(I'm pretty sure that I cannot do this in __init__() because of the weird, semi-magical nature of BuildStep.)

Change History

Changed 6 weeks ago by ccooper

  • cc ccooper@… added

I'm hitting this too in 0.8.0. Specifically, if I don't specify a description for my build step, buildbot attempts to build one for me by walking the properties, some of which may not be set if doStepIf is false. (The workaround is, of course, to always provide a description.)

Changed 2 weeks ago by dustin

  • keywords tests added
  • milestone changed from 0.8.2 to 0.8.3

Let's see if we can get some tests to verify this. There are a lot of chicken-and-egg problems like this with the properties.

Note: See TracTickets for help on using tickets.