[Buildbot-commits] [Buildbot] #2076: GitPoller initiates bad builds

[Buildbot trac]

#2076: GitPoller initiates bad builds
----------------------------+----------------------
Reporter:  dwyerk           |       Owner:
    Type:  support-request  |      Status:  new
Priority:  major            |   Milestone:  ongoing
 Version:  0.8.4p2          |  Resolution:
Keywords:                   |
----------------------------+----------------------

Old description:

> I have a git repo with two branches, master and stable. I have configured
> one GitPoller to watch for changes on master. Master and stable have
> diverged in some serious ways, but most of the time it's still possible
> and preferable to merge a change from stable into master.
>
> When I make a change to stable and merge it to master, GitPoller triggers
> two builds. The first is based off of the commit hash for the original
> change to stable, and the second is based off of the commit hash for the
> merge. The first build will always fail because the Git buildstep will
> reset the repo to stable's hash, and the rest of the steps will not be
> able to find the files that they expect, since they were setup to build
> master, not stable.
>
> The second build will work, because it resets the repo to the merge
> commit, which is a state that actually exists on the master branch.
>
> So is this a supported configuration? In this case, what I really want
> GitPoller to do is ignore that first build, since the hash doesn't refer
> to the branch that GitPoller is supposed to be watching.

New description:

 I have a git repo with two branches, master and stable. I have configured
 one GitPoller to watch for changes on master. Master and stable have
 diverged in some serious ways, but most of the time it's still possible
 and preferable to merge a change from stable into master.

 When I make a change to stable and merge it to master, GitPoller triggers
 two builds. The first is based off of the commit hash for the original
 change to stable, and the second is based off of the commit hash for the
 merge. The first build will always fail because the Git buildstep will
 reset the repo to stable's hash, and the rest of the steps will not be
 able to find the files that they expect, since they were setup to build
 master, not stable.

 The second build will work, because it resets the repo to the merge
 commit, which is a state that actually exists on the master branch.

 So is this a supported configuration? In this case, what I really want
 GitPoller to do is ignore that first build, since the hash doesn't refer
 to the branch that GitPoller is supposed to be watching.

--

Comment (by dustin):

 It's a scheduler option, not a poller option.

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