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. On 9/4/2012 10:33 AM, Brad Roberts wrote: > Looks simple enough. I'll try to get it done tonight. > > On 9/4/2012 10:23 AM, Robert Clipsham wrote: >> Hi all, >> >> I don't know if you've seen this, but I thought I'd let you know: >> >> https://github.com/blog/1227-commit-status-api >> >> It does a similar job to what the auto-tester GreaseMonkey scripts already >> do but it's built into GitHub and modifies >> the merge button to make it more obvious. Could be worth looking into adding >> to the auto-tester at some point. >> >> I would assume at some point they'll build on this to allow pull requests to >> be triaged based on the information. >> >> -- >> Robert > > _______________________________________________ > dmd-internals mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals > _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
