Actually about "transferring the logic to the webapp" I'm saying that it's complicated mainly because I don't know how to do it. Ondrej knows how to work with it better than me so if he says that this is straightforward and preferred solution I'll certainly agree.
Stefan On 13 December 2011 19:23, krastanov.ste...@gmail.com < krastanov.ste...@gmail.com> wrote: > > > 2011/12/13 Ondřej Čertík <ondrej.cer...@gmail.com> > >> On Tue, Dec 13, 2011 at 2:04 AM, krastanov.ste...@gmail.com >> <krastanov.ste...@gmail.com> wrote: >> > That's great. I'll start using it. Still, I have a few questions: >> > >> > Is it a bad idea to run it like this: """while ((1)); do ./sympy-bot >> all; >> > done;""" ? That way I can leave it and it will run forever. I have >> >> That's fine. But see below. >> >> > .sympy-bot config file so it will not ask for password. >> > >> > If two developers are running it at the same time what stops them from >> > making duplicate reports? I suppose that before each test it checks if >> tests >> > were already done (instead of checking this at the beginning when >> building >> > the list of open pull requests before running any tests). But this still >> > leaves about 20 minutes (between the start of the tests and their >> posting) >> > for somebody else to start a duplicate test. >> > >> > And how does it check if tests were already done (it pools the GAE app >> > probably and it also checks the architecture)? Are tests on different >> python >> > versions and different architecture considered different? >> >> Unfortunately this is *not* implemented yet. So you still have to use >> your script. The GAE app should decide how many tests we need for each >> pull request for the given platform (typically just one). Usually, >> your platform might be different than mine (you might be 32, I am 64, >> or you might have a different version of Python like 2.6 and I have >> 2.7, and so on). Imho there should be just a few actuall comments in >> the github pull request with the report, everything else should go >> into the web app (so that we don't spam the pull request, but still >> have all the tests). >> >> What we can do is to modify sympy-bot to *only* upload to the webapp, >> then you can simply leave it running in a loop and we will have all >> the tests and no spamming. Then the webapp just needs to decided >> somehow when and how to report into the pull request. I think that's a >> great solution for now. >> >> So let's make a special option in sympy-bot to only upload to the web >> app and *not* commenting into the pull request, and then let's run >> this in a loop at my server for 2.x and 3.x pythons. It will not be >> super efficient, but we don't have that many pull requests and it just >> takes a few hours to run tests on all pull requests, so that's a good >> engineering solution for now. Once we have that, the only thing to do >> is to start improving the GAE app to be more clever about all the data >> that it has. One idea is that for example once it has both 2.x and 3.x >> tests for at least one platform, it can post a link to the GAE pull >> request page into the github pull request. So that we can just click >> the link and see the latest status. >> > Ok, but then the author will fix the problem and a new test should be > done. If I understand right the current solution is to run again > """./sympy-bot all""". This will either spam the PRs that do not need > testing or if there is no-comment flag just run the tests again. This is > inefficient as the test are ran twice and complicated as additional logic > in the web app must decide when to report. Then one must find out how the > webapp can log in to github to make comments. > > It's **much** simpler just to run the tests only when they are needed. For > the moment my script does this by comparing the branch hash with the hash > from the last test. It does it in a hackish way that should be cleaned up > but I certainly prefer those 20 lines of code instead of a complicated > webapp logic that does the same thing and runs tests multiple times without > any change in the code that is tested. > > For example while Ondrej was using """sympy-bot all""" my script was > running and seeing that the tests done by Ondrej were up-to-date it did not > redo them. > > I'm not saying that my script is a better solution, certainly it is not. > But I don't think that the current implementation of "sympy-bot all" is the > best possible. Mainly because transferring all the logic about > when-to-test-and-when-to-report to the webapp is 1) not yet done, 2) too > complicated 3) somebody said it takes time from actually developing sympy > > Anyway, if it works I'll happily donate some CPU time for "sympy-bot all" > if needed :) > > Stefan > >> >> Ondrej >> >> > >> > Stefan >> > >> > 2011/12/13 Ondřej Čertík <ondrej.cer...@gmail.com> >> >> >> >> Hi, >> >> >> >> Here are some new features in sympy-bot that we implemented >> >> (https://github.com/sympy/sympy-bot): >> >> >> >> * Review "all" and "mergeable": >> >> >> >> Use it like this: >> >> >> >> sympy-bot review all >> >> >> >> or >> >> >> >> sympy-bot review mergeable >> >> >> >> and it will review all open pull requests or all mergeable pull >> >> requests. It will ask for your login (once) and then just keep >> >> running. >> >> I leave it running in the "screen" environment on my server. If you >> >> have some spare cycles, just run the following from time to time: >> >> >> >> sympy-bot review mergeable >> >> sympy-bot -3 review mergeable >> >> >> >> you can run this over night. >> >> >> >> >> >> * Report conflicts >> >> >> >> Now the log shows conflicting files *and* the actual conflicts. So >> >> from now on, we can simply click on the full report and see the >> >> conflicts and if it is some easy conflict (typically changed imports), >> >> one can choose to simply fix it manually and merge the pull request. >> >> If the conflict is large, one would ask the reviewer to rebase. >> >> >> >> * "-m" option >> >> >> >> One can now merge with a custom commit (or not merge at all). See the >> >> README. >> >> >> >> >> >> I think the last big piece of the puzzle is to implement "sympy-bot >> >> work" to wait for "orders" from the web application (by polling it). >> >> And the web application would send it some high priority pull requests >> >> (like the newly open ones) and so on. This I would simply leave >> >> running at the server. >> >> >> >> 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. >> >> -- >> 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.
