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.

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.

Reply via email to