Actually my "solution" is to load the whole comment page and regex out the hash. It's only two lines of code but I'm almost ashamed of them. That is why I was saying all the time that the script is only a workaround. I'll close the pr and open an issue about it. Isn't the hash already in some database in the webapp? If not I can just add such database and use a query to the webapp. Is this what you were thinking about?
2011/12/14 Ondřej Čertík <ondrej.cer...@gmail.com> > On Tue, Dec 13, 2011 at 1:38 PM, Aaron Meurer <asmeu...@gmail.com> wrote: > > The only way to eliminate the kind duplication that you talked about > > is to have the webapp serve requests. The rest could be distributed, > > though I think that certain other things should also be centralized. > > > > Ondrej, if you implement the webapp framework for this, I can help > > with the client-side code (I don't know anything about webapp > > programming is all). Here are my basic ideas about what it would do: > > > > The webapp would keep track of everything. Which pull requests have > > been merged, with which hashes, and with which architectures, pythons, > > etc. > > > > When a user runs ./sympy-bot work, it will start by registering with > > the webapp all the Python versions it has, along with what > > architectures they are, if they have gmpy, etc. By default, it will > > just use a heuristic to check this (try python2.5 python2.6, etc.). > > But the user can also specify in the config file exact executable > > paths to more Python versions, so that for example, it can specify > > both 32-bit and 64-bit versions of Python. (It actually should be a > > command to be run, not an executable path, as for example, in Mac OS > > X, you get the different architectures with arch -i386 or arch -x86_64 > > followed by the executable). > > > > Then, the webapp will use the knowledge of what needs to be done and > > what is available and serve requests. In the start, it could just be > > random (but still preventing duplicates). Later on, we can implement > > some smart heuristics and use a priority queue. For example, if only > > one client has 64-bit Python 2.5, that should be prioritized for that > > client. Also, we can prioritize the pull requests based on various > > heuristics. > > > > The webapp would give each client say 30 min. to complete the review > > before it puts it back in the queue, in case it goes offline or > > something (we can increase this for things like pypy or cache off, if > > we ever add that). > > > > Another thing that we should implement is testing of master. Just do > > it in the same way as the pull requests, except of course there will > > be no GitHub comments. There will just be a separate place in the > > webapp with master tests. I'd like to do smart things with this in > > the future, like automatically check if a test failure in a pull > > request is also present in master. > > > > Finally, there's the question of how to report the tests in GitHub. > > We don't want to spam comments. I think what we should do is create a > > user for SymPy-bot, and have that user, through the webapp, do all > > reports. This will eliminate the need for GitHub logins, I believe. > > I think we should just create one comment per new hash in the pull > > request, and have the app edit that comment. I just found out that > > you can do tables in Markdown, which are support by GitHub comments. > > You just do the table in html. For example, try pasting this into a > > GitHub comment and clicking on preview: > > > > <table border="1"> > > <tr> > > <th>Month</th> > > <th>Savings</th> > > </tr> > > <tr> > > <td>January</td> > > <td>$100</td> > > </tr> > > </table> > > > > So we should create a table with all the test results. > > > > The only problem with this is that if the app uploads a comment saying > > the tests passed, but then edits it to say the tests failed (because > > they passed first in Python 2 but then failed in Python 3, for > > example), then the user will not be notified by email of the failures, > > because edits to not send out emails. I need to check this, actually. > > I wonder if you edit a GitHub comment and add a @username if it will > > still send the email. > > > > Again, I don't know how to architecture this, but once it is started, > > I can help implementing some of the advanced features I mentioned > > here. > > Yes, that's exactly what I have in mind. But obviously, it is still > quite a bit of work. > > Stefan's solution is kind of ok, but not bullet proof --- as I said, > there are a lot of configurations of Python and we only don't want to > test the exact same configuration twice. > > In any case, Stefan, if you'd be willing to implement your hash > checking into "sympy-bot review all", that'd be great. Then we can > close your pull request and keep working on a common code base. > > 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. > > -- 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.
