[dmd-internals] GitHub commit status API

[Don Clugston]

On 6 September 2012 09:31, Brad Roberts <braddr at puremagic.com> wrote:
> On 9/6/2012 12:26 AM, Don Clugston wrote:
>> On 4 September 2012 19:43, Brad Roberts <braddr at puremagic.com> wrote:
>>> Hrm.. there's one important difference between the way this api is designed and the way the auto-tester tests the pull
>>> requests.  The api tags a specific sha, which would be the tip of the pull requests revision history.  That's fine if
>>> the merge to master is purely a fast-forward merge (ie, the pull request is based on the tip of the master tree and is
>>> purely additive).  However, if the pull request is NOT based off the tip of the tree, then a merge is involved and the
>>> auto-tester is testing the result of that merge, NOT the pull request pre-merge.
>>>
>>> I can go ahead and apply the status to the pull requests tip sha, but it'll be a little misleading in that it's entirely
>>> possible that the pull request builds w/o a merge to master but doesn't with.  Likely to be a fairly rare occurrence,
>>> but worth noting.
>>
>> It's not rare at all, I've seen it very many times.
>
> Sorry, I was excluding the case where it's not mergable.  There's a lot of cases where it builds w/in just the pull
> request, but isn't mergeable due to conflicting changes.  I think that case is fine to report failure for, since it
> requires attention before the pull request is useful.  Are you aware of a significant number that _do_ merge but then
> fail to build/test post-merge but succeed w/o a merge?

I've definitely seen some, usually related to forward references (any
compiler change that changes the order of evaluation can easily cause
other stuff to break).

I presume this would at least this would still catch the case where it
merges but isn't compatible with druntime or phobos? There are quite a
few open pull requests right now where that's true (a compiler change
that worked with an old Phobos, but not with the current one).