Hi, On 26 April 2011 16:59, Ondrej Certik <ond...@certik.cz> wrote:
> On Tue, Apr 26, 2011 at 4:50 PM, Ondrej Certik <ond...@certik.cz> wrote: > > On Tue, Apr 26, 2011 at 9:38 AM, Tom Bachmann <ness...@googlemail.com> > wrote: > >> Hi, > >> > >> so on my bus ride today I figured it would be nice to have an > >> automated way to see to what extent open pull requests play along > >> nicely. In particular this would be good when over the summer about > >> ten of us will be working on fairly large projects: Here it would be > >> helpful to see if there are conflicts between branches that are not > >> even up for review yet. > >> > >> So I hacked together a small script [1]. The inspiration of this comes > >> from linux-next. > >> > >> Here is the description from the file: > >> > >> # Tool to aggeregrate several branches, automatically merge them (if > >> possible) > >> # and create statistics about unit tests. > >> # > >> # Usage: sympy-next.py repo branches out-dir > >> # where > >> # repo is is the location of a clean repository (possibly > >> empty) > >> # that is going to be used. > >> # branches is a file containing a list of branches, one entry per > >> line, like > >> # so: > >> # https://github.com/sympy/sympy.git master > >> # /home/ness/src/sympy 360_zoo > >> # ... > >> # out-dir Is the name of a directory where output is going to be > >> created. > >> # > >> # This program walks the list of branches, fetches all of them, and > >> tries to > >> # merge them in order. If there are merge-failures the branch is > >> dropped. After > >> # all successful merges are done, the unit tests are run. Finally a > >> report is > >> # created of which branches could be merged, and which tests passed. > >> # All commands run are logged to a file in the output directory. > >> > >> Notes: > >> 1) This is hardly well-tested. All improvements are welcome. > >> 2) The html output is ugly, and so is the code that creates it. This > >> is the display of my complete lack of web-programming capabilities. > >> 3) The tests are currently only run after all merges are complete, so > >> there is no way to tell which branch introduced the problem. > >> 4) Also the output is not at all pruned, so as branches go stale, and > >> also with time, it will probably become too long. > >> 5) If/When we set up a new buildbot there should probably be a nicer > >> way to do this. But: > >> 6) Is there any interest in this, and if so is anyone willing to run > >> this script (or something similar) more or less manually for a while? > >> I would imagine that person to mainting a branches file where > >> additions/deletions can be requested by email, and then the script is > >> run about once a day, with results published somewhere and perhaps > >> some nagging emails being sent around. I suppose with a bit of > >> fiddling this could be done basically automatically using a cron-job. > > > > Absolutely! I have a server, which currently is running > > planet.sympy.org, and I would like to migrate the planet to some other > > online service, and then use that server for exactly the purpose of > > testing sympy patches (in several python installations and so on). > > > > One can also use this github pull request API: > > > > http://develop.github.com/p/pulls.html > > > > to automatically determine new pull requests and generate some > > statistics, e.g. if all tests run and so on. > > So elaborating more, here is what we should do: > > 1) the sympy-next would automatically determine over the pull request > github API that a new pull request was added, or more patches pushed > to it. It would generate an automatic comment into the pull request, > with saying "All tests pass + link to the test results", or "Tests > failed + link to the stats and more details". > > 2) If the pull request is reviewed and all tests run (as tested by > sympy-next and reported in the comment in the pull request), one can > just click "Merge" in the pull request: > > https://github.com/blog/843-the-merge-button > > to merge it in. This will speedup trivial patch merging a lot, as I > don't need to run it on my machine, as long as we trust sympy-next, > but we can, by simply manually examining the logs, making sure that > all is ok. > A problem with this plan is that you need two machines (32- and 64-bit) to believe automated tests (at least on Linux). > > > Ondrej > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > Mateusz -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
