Hi, On Mon, Aug 19, 2013 at 12:13 AM, Aaron Meurer <[email protected]> wrote: > FWIW, the ideal solution would be if it did what Travis does and > tested against pull requests and commented there for any failures. > Almost no one looks at the Travis logs against master; people look at > them against pull requests. But if this is not technically possible, > or if it would require more build power than you are willing to > donate, then we will need to find another solution.
I'm sure this is technically possible, but I don't personally know how to do it. As a matter of interest, how many commits do you get per day to pull requests in Sympy? > A reasonable workaround might be to comment on the pull request that > (apparently) broke master. Since the HEAD of master is almost always a > GitHub pull request merge commit, this should work. The disadvantage > of course is that you're telling someone that their pull request broke > something *after* it was merged. Right - I must say I don't routinely look at the github page for the pull request after it is merged unless a notification reaches me by email. We have so far found it adequate to check the builders on the web page fairly often. As the person who usually does merges for two of our projects, I like to check how the build looks after I do the merge. If I also got email alerts for failing builds and they also went to the person responsible for the commit, I would feel properly warned, but this may not suit your workflow, Best, Matthew -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
