[Buildbot-commits] [Buildbot] #2703: handle step interruption properly

Buildbot trac trac at buildbot.net
Sun Feb 23 14:17:06 UTC 2014


#2703: handle step interruption properly
-------------------+--------------------
Reporter:  tardyp  |       Owner:
    Type:  task    |      Status:  new
Priority:  major   |   Milestone:  0.9.0
 Version:  master  |  Resolution:
Keywords:          |
-------------------+--------------------
Description changed by dustin:

Old description:

> There are some subtleties to handle step interrupts.
>
> For shellcommands this works, but for master steps its more complex.
> especially trigger would need special attention.
>
> <tardyp> djmitche, in the case of a new style step, how are you supposed
> to interrupt a step?
> »» tardyp converting Trigger to new style..
> <+djmitche> tardyp: has that changed?
> <tardyp> well if I run interrupt(), we are in the middle of run(), which
> would be yielding someting
> <tardyp> old style step would just call self.finished() so can skip
> waiting
> <+djmitche> interrupt will also interrupt a running command
> <+djmitche> so this is only a problem when run() isn't executing a
> command
> <tardyp> I realize that trigger's interrupt is badly written
> <tardyp> it should cancel the requests
> <tardyp> and stop the builds
> <+djmitche> yes
> <+djmitche> there should be some instructions for step authors who are
> not just executing commands to poll self.stopped or something like that
> <tardyp> the first is easy, end the second need the stop rpc
> <+djmitche> also, initiating a new command after an interrupt should
> immediately fail
> <+djmitche> I don't think it necessarily should stop the triggered builds
> <tardyp> well, we have hacks to do so, as my user were requesting this
> loud
> <+djmitche> what if those requests got merged?
> <tardyp> it make sense to release the buildfarm, when like use a single
> build can trigger douzens of parralel builds
> <tardyp> the algo is to claim_cancel the buildrequests first
> <tardyp> then if the buildrequests are claimed, get to the build status
> and stop it
> <+djmitche> I suppose if we're collapsing requests instead, then if the
> request was collapsed, you just don't cancel a build
> <tardyp> so I believe this works with the collapsing
> <+djmitche> yeah
> <tardyp> if it is callapsed then its claimed
> <+djmitche> as long as it's via the data API I think that's OK :)

New description:

 There are some subtleties to handle step interrupts.

 For shellcommands this works, but for master steps its more complex.
 especially trigger would need special attention.

 {{{
 <tardyp> djmitche, in the case of a new style step, how are you supposed
 to interrupt a step?
 »» tardyp converting Trigger to new style..
 <+djmitche> tardyp: has that changed?
 <tardyp> well if I run interrupt(), we are in the middle of run(), which
 would be yielding someting
 <tardyp> old style step would just call self.finished() so can skip
 waiting
 <+djmitche> interrupt will also interrupt a running command
 <+djmitche> so this is only a problem when run() isn't executing a command
 <tardyp> I realize that trigger's interrupt is badly written
 <tardyp> it should cancel the requests
 <tardyp> and stop the builds
 <+djmitche> yes
 <+djmitche> there should be some instructions for step authors who are not
 just executing commands to poll self.stopped or something like that
 <tardyp> the first is easy, end the second need the stop rpc
 <+djmitche> also, initiating a new command after an interrupt should
 immediately fail
 <+djmitche> I don't think it necessarily should stop the triggered builds
 <tardyp> well, we have hacks to do so, as my user were requesting this
 loud
 <+djmitche> what if those requests got merged?
 <tardyp> it make sense to release the buildfarm, when like use a single
 build can trigger douzens of parralel builds
 <tardyp> the algo is to claim_cancel the buildrequests first
 <tardyp> then if the buildrequests are claimed, get to the build status
 and stop it
 <+djmitche> I suppose if we're collapsing requests instead, then if the
 request was collapsed, you just don't cancel a build
 <tardyp> so I believe this works with the collapsing
 <+djmitche> yeah
 <tardyp> if it is callapsed then its claimed
 <+djmitche> as long as it's via the data API I think that's OK :)
 }}}

--

-- 
Ticket URL: <http://trac.buildbot.net/ticket/2703#comment:1>
Buildbot <http://buildbot.net/>
Buildbot: build/test automation


More information about the Commits mailing list