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

[Pierre Tardy]

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/20170428/881bc8e7/attachment.html>