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

[Bill Deegan]

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/b2601224/attachment.html>