[users at bb.net] DVCS commits vs pull requests and buildbot

[Pierre Tardy]

I think the original intent was before testing pull request was a thing.
Now there is nothing preventing having a webhook for both PR and pushes.
That is what buildbot travis implement

You just need to setup the changefilter accordingly.

Pierre


On Tue, May 16, 2017 at 7:55 PM Bill Deegan <bill at baddogconsulting.com>
wrote:

> Is the intent that a user would setup either webhook for repo pushes or
> pull requests, and not both?
>
> -Bill
>
> On Fri, Apr 28, 2017 at 1:24 AM, Pierre Tardy <tardyp at gmail.com> wrote:
>
>> Hi Bill,
>>
>> The change system in buildbot is made to be relatively simple.
>> I am not sure we really want to duplicate the VCS commit hierarchy  (1
>> commit == 1 change).
>> git/hg commit list is not a hierarchy this is an oriented graph (with
>> merge commits)
>> I think this would complicate a lot the data model if we supported all
>> that.
>>
>> The model of buildbot is to listen for all changes and categorize them by
>> branch.
>> Once the tree is stable enough, we gather all those changes, and trigger
>> a build on the latest revision we saw for that branch.
>>
>> The Pull request model indeed adds a new concept of target branch. A pull
>> request is a development branch that a developer wants to get merged on a
>> mainline target branch.
>> I think what we would need in order to better support this model is to
>> add the concept of target branch to buildbot.
>>
>> The pull request hook would create a bunch of changes targeted to a
>> branch named by the PR, and target_branch is the branch on which we want to
>> merge.
>> branch: refs/pulls/1234
>> target_branch: master
>> revision: abcdef
>>
>> The Scheduler can then gather those changes grouped by branch (no change
>> needed)
>> Then the Source steps needs to be changed in order to account for this:
>> it needs to checkout revision as usual, and then needs to merge into
>> target_branch. (before running the tests)
>>
>> as for now, buildbot does not support this concept of target_branch and
>> we need to workaround this a bit.
>> With github there is the handy concept of magic ref
>> "refs/pull/1234/merge", which does the merge automatically.
>> Other servers does not support that. gitlab does not have the merge magic
>> branch, so gitlab users cannot easily check against latest version of
>> target branch.
>> Also I think some other PR model require to pull the PR code from a
>> different repo of the target repo.
>> e.g we would need to do git pull https://github.com/tardyp/buildbot mybranch,
>> instead of git pull origin refs/pull/1234/merge
>>
>>
>> Gerrit also has a concept of target_branch, but the model of how change
>> are updated is slightly different.
>>
>> So there is still some work to do in Buildbot infra in order to enhance
>> the pre-commit/pre-submit checks story.
>> Any help would be greatly appreciated
>>
>> Pierre
>>
>>
>> On Thu, Apr 27, 2017 at 3:10 AM Bill Deegan <bill at baddogconsulting.com>
>> wrote:
>>
>>> Greetings,
>>>
>>> I've just upgraded to 0.9.6 and am working on fixing the bitbucket
>>> webhook and polling logic and got to wondering if Buildbot should handle
>>> pullrequests differently than commits.
>>>
>>> Should there be a separate object/table for each and commits optionally
>>> would be included in pull requests?
>>>
>>> Unless I"m mistaken the current implementation is to handle pull
>>> requests and just stick their changes (as many are pushed by the change
>>> hook of the provider (github,etc)) into the database and work from that.
>>>
>>> Thus losing the hierachical info about pull request/commits?
>>>
>>> Is there value in keeping that?
>>>
>>> -Bill
>>> _______________________________________________
>>> users mailing list
>>> users at buildbot.net
>>> https://lists.buildbot.net/mailman/listinfo/users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/users/attachments/20170516/0509aea2/attachment.html>