Try and be patient Jacques, I'm also having trouble understanding what you are saying.
Here's what I've been able to understand so far: - Pre-gradle OFBiz tests run fine on buildbot - Gradle OFBiz fails on buildbot with a complaint that the default ports are in use - The test framework in OFBiz has never supported port offset - Jacques thinks that maybe using a port offset for tests will fix the problem but he's unsure why Is that mostly correct Jacques? Is there a possibility that buildbot isn't correctly shutting down OFBiz from the previous test run and the ports are being left open? Just a guess, I don't know much about buildbot but that's the usual cause of the default ports being unavailable in my experience. Regards Scott On 30 January 2017 at 21:08, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote: > Come on Taher, > > As I said below (my last message) BuildBot is only revealing a symptom. > > I already explained in this thread http://markmail.org/message/h4 > i7cn4i2btugdwn: > > <<Prior to Gradle migration we were not using the 8080 port during tests. > For instance we could have an OFBiz instance running, playing with its UI > and then run tests on another instance or vice-versa. > This is no longer possible because now the port 8080 (and others) are kept > open while running tests. So far it was only a "small" annoyance, but it's > now blocking BuildBot because infra puppetized the BuildBot slaves > https://s.apache.org/pWQD.>> > > I suggest that you test by yourself to be convinced. > > I also wrote in this same email <<Before anything else, I will though ask > infra why Tomcat is always running on these hosts...>> > > I did, now waiting their answer... and focusing on other matters in the > meantime... > > Jacques > > > Le 29/01/2017 à 14:27, Taher Alkhateeb a écrit : > >> What does gradle have to do with blocking these ports? This is stuff >> related to Tomcat. There is nothing in both ant and gradle that has >> anything to do with these ports afaik. >> >> On Jan 29, 2017 4:16 PM, "Jacques Le Roux" <jacques.le.r...@les7arts.com> >> wrote: >> >> Taher, >>> >>> I did not say that "ant run-tests" can use portoffset. Indeed it's not, >>> and I was overzealous when, long ago and yesterday in r1780660, I changed >>> the Java code of tests for that (related with portoffset). Because I did >>> not change how the tests are running in pre Gradle versions. Actually I >>> was >>> then unsure and preferred to cover all cases. So, I repeat: we never >>> use/block ports (at least 8080 and I guess 8443) when running tests in >>> pre >>> Gradle versions. >>> >>> For instance if you look for >>> >>> f_ofb_15.addStep(Compile(command=["ant" , "load-demo"], >>> and >>> f_ofb_15.addStep(Compile(command=["ant" , "run-tests"], >>> >>> in https://svn.apache.org/repos/infra/infrastructure/buildbot/a >>> egis/buildmaster/master1/projects/ofbiz.conf (for committers only) >>> >>> You will see that we don't use portoffset in Buildbot and it works well: >>> >>> https://ci.apache.org/projects/ofbiz/logs/15.12/html/ (ran yesterday) >>> >>> But since Gradle migration something has surely changed. As Buildbot >>> shows >>> (it's a side effect here, but it's also Buildbot role to track >>> regressions), the ports are used(?)/blocked when running tests in post >>> Gradle versions. >>> I believe the best for us is to remove that, if it's possible. I'll have >>> a >>> look in Config.java. I'll not feel offended if someone beats me on it... >>> >>> Thanks >>> >>> Jacques >>> >>> >>> Le 29/01/2017 à 11:12, Taher Alkhateeb a écrit : >>> >>> Okay, thank you for the efforts Jacques. >>>> >>>> The only thing that I suspect is related might be in Config.java where >>>> the >>>> portoffset is evaluated. I don't think I've changed the logic, and so I >>>> suspect that it is not related to Gradle. If the tests do not run on a >>>> portoffset, then I suspect perhaps they don't do the same on ant either. >>>> >>>> On Sun, Jan 29, 2017 at 12:57 PM, Jacques Le Roux < >>>> jacques.le.r...@les7arts.com> wrote: >>>> >>>> Hi Taher, >>>> >>>>> Prior to Gradle migration we were not using the 8080 port during tests. >>>>> For instance we could have an OFBiz instance running, playing with its >>>>> UI >>>>> and then run tests on another instance or vice-versa. >>>>> >>>>> This is no longer possible because now the port 8080 (and others) are >>>>> kept >>>>> open while running tests. So far it was only a "small" annoyance, but >>>>> it's >>>>> now blocking BuildBot because infra puppetized the BuildBot slaves >>>>> https://s.apache.org/pWQD. >>>>> >>>>> And, I don't know why and this could be a question to infra, for a >>>>> reason >>>>> there is always a Tomcat instance running on port 8080 these hosts >>>>> https://s.apache.org/iSaN >>>>> >>>>> I thought we could bypass this issue by using portoffset with >>>>> testIntegration task since it's now required. But I just tested locally >>>>> and >>>>> it seems to not work. I'm not quite sure and will try a last thing >>>>> directly >>>>> "on" Buildbot. If it does not work we have to think about removing this >>>>> need of open ports while running tests, IOW to remove this regression >>>>> introduced with Gradle. >>>>> >>>>> Before anything else, I will though ask infra why Tomcat is always >>>>> running >>>>> on these hosts... >>>>> >>>>> Jacques >>>>> >>>>> >>>>> Le 27/01/2017 à 18:15, Taher Alkhateeb a écrit : >>>>> >>>>> Why do we need to run the tests on portoffset? >>>>> >>>>>> On Fri, Jan 27, 2017 at 7:48 AM, Jacques Le Roux < >>>>>> jacques.le.r...@les7arts.com> wrote: >>>>>> >>>>>> Ah, I forgot to say, that I have dropped BuildBot support for R12 and >>>>>> R13. >>>>>> >>>>>> Also that the pre-Gradle versions don't need portoffset >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le 27/01/2017 à 05:29, Jacques Le Roux a écrit : >>>>>>> >>>>>>> Le 27/01/2017 à 05:14, Jacques Le Roux a écrit : >>>>>>> >>>>>>> But in the case of running integration tests with a portoffset we >>>>>>>> have >>>>>>>> >>>>>>>> an issue which is blocking BuildBot now for trunk and >>>>>>>>> >>>>>>>>> R16 >>>>>>>>> >>>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >
