<div dir="ltr">Hi Bill,<div><br></div><div>The change system in buildbot is made to be relatively simple.</div><div>I am not sure we really want to duplicate the VCS commit hierarchy  (1 commit == 1 change).</div><div>git/hg commit list is not a hierarchy this is an oriented graph (with merge commits)</div><div>I think this would complicate a lot the data model if we supported all that.</div><div><br></div><div>The model of buildbot is to listen for all changes and categorize them by branch.</div><div>Once the tree is stable enough, we gather all those changes, and trigger a build on the latest revision we saw for that branch.</div><div><br></div><div>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.</div><div>I think what we would need in order to better support this model is to add the concept of target branch to buildbot.</div><div><br></div><div>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.</div><div>branch: refs/pulls/1234</div><div>target_branch: master</div><div>revision: abcdef</div><div><br></div><div>The Scheduler can then gather those changes grouped by branch (no change needed)</div><div>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)</div><div><br></div><div>as for now, buildbot does not support this concept of target_branch and we need to workaround this a bit.</div><div>With github there is the handy concept of magic ref "refs/pull/1234/merge", which does the merge automatically.</div><div>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.</div><div>Also I think some other PR model require to pull the PR code from a different repo of the target repo.</div><div>e.g we would need to do git pull <a href="https://github.com/tardyp/buildbot">https://github.com/tardyp/buildbot</a> mybranch, instead of git pull origin refs/pull/1234/merge</div><div><br></div><div><br></div><div>Gerrit also has a concept of target_branch, but the model of how change are updated is slightly different.</div><div><br></div><div>So there is still some work to do in Buildbot infra in order to enhance the pre-commit/pre-submit checks story.</div><div>Any help would be greatly appreciated</div><div><br></div><div>Pierre</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 27, 2017 at 3:10 AM Bill Deegan <<a href="mailto:bill@baddogconsulting.com">bill@baddogconsulting.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Greetings,<br><br></div>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.<br><br></div>Should there be a separate object/table for each and commits optionally would be included in pull requests?<br><br></div>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.<br><br></div>Thus losing the hierachical info about pull request/commits?<br><br></div>Is there value in keeping that?<br><br></div>-Bill<br></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@buildbot.net" target="_blank">users@buildbot.net</a><br>
<a href="https://lists.buildbot.net/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.buildbot.net/mailman/listinfo/users</a></blockquote></div>