Tests and Buildbot are OK again

[Jacques Le Roux]

Hi,

Buildbot is back again, pfew...!

All tests are passing there but R16.11 which passes locally. I'll try to see why it's a pb on Buildbot.
I guess I have an idea: upgrading to Gradle 3 the Infra team lets the daemon in place which is a default now (beware of that in prod!). I created
INFRA-13643, let's see

Also the RAT tests (framework-trunk and plugins-trunk) don't run because of an hardware issue on the slave where they are supposed to build, Infra
waits for a fix...

Also I noticed that when framework-trunk tests fail locally no runtime\logs\test-results is created.

When you run tests in ofbiz-framework-buildbot (as I do in Buildbot) all is OK

https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework-buildbot/trunk is a branch which uses svn:externals to grab all the parts. Here are the
definitions

C:\projectsASF\ofbiz-framework-buildbot>svn propget svn:externals
^/ofbiz/ofbiz-plugins/trunk plugins
^/ofbiz/ofbiz-framework/trunk/framework framework
^/ofbiz/ofbiz-framework/trunk/tools tools
^/ofbiz/ofbiz-framework/trunk/gradle gradle
^/ofbiz/ofbiz-framework/trunk/applications applications
^/ofbiz/ofbiz-framework/trunk/themes themes
^/ofbiz/ofbiz-framework/trunk/hot-deploy hot-deploy
^/ofbiz/ofbiz-framework/trunk/lib lib
^/ofbiz/ofbiz-framework/trunk/runtime runtime
^/ofbiz/ofbiz-framework/trunk/settings.gradle settings.gradle
^/ofbiz/ofbiz-framework/trunk/build.gradle build.gradle
^/ofbiz/ofbiz-framework/trunk/common.gradle common.gradle
^/ofbiz/ofbiz-framework/trunk/gradlew gradlew

This is only while waiting for the pullAllPluginsSource Gradle task and should not be used in development.

HTH

Jacques

[Jacques Le Roux]

Ah, forgot to say that it seems the issue we get with R16 on Buildbot is the same than what I get locally with framework trunk alone: no
runtime\logs\test-results is created.

The last we have for 16 is from 2017-02-02 10:25:37 https://ci.apache.org/projects/ofbiz/logs/16.11/

When we lastly ran tests https://ci.apache.org/builders/ofbiz-branch16 today

I doubt it's a change between r1781363 and r1786335 but I'll check that 1st

Jacques


Le 10/03/2017 à 14:20, Jacques Le Roux a écrit :

> Hi,
>
> Buildbot is back again, pfew...!
>
> All tests are passing there but R16.11 which passes locally. I'll try to see why it's a pb on Buildbot.
> I guess I have an idea: upgrading to Gradle 3 the Infra team lets the daemon in place which is a default now (beware of that in prod!). I created
> INFRA-13643, let's see
>
> Also the RAT tests (framework-trunk and plugins-trunk) don't run because of an hardware issue on the slave where they are supposed to build, Infra
> waits for a fix...
>
> Also I noticed that when framework-trunk tests fail locally no runtime\logs\test-results is created.
>
> When you run tests in ofbiz-framework-buildbot (as I do in Buildbot) all is OK
>
> https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework-buildbot/trunk is a branch which uses svn:externals to grab all the parts. Here are the
> definitions
>
> C:\projectsASF\ofbiz-framework-buildbot>svn propget svn:externals
> ^/ofbiz/ofbiz-plugins/trunk plugins
> ^/ofbiz/ofbiz-framework/trunk/framework framework
> ^/ofbiz/ofbiz-framework/trunk/tools tools
> ^/ofbiz/ofbiz-framework/trunk/gradle gradle
> ^/ofbiz/ofbiz-framework/trunk/applications applications
> ^/ofbiz/ofbiz-framework/trunk/themes themes
> ^/ofbiz/ofbiz-framework/trunk/hot-deploy hot-deploy
> ^/ofbiz/ofbiz-framework/trunk/lib lib
> ^/ofbiz/ofbiz-framework/trunk/runtime runtime
> ^/ofbiz/ofbiz-framework/trunk/settings.gradle settings.gradle
> ^/ofbiz/ofbiz-framework/trunk/build.gradle build.gradle
> ^/ofbiz/ofbiz-framework/trunk/common.gradle common.gradle
> ^/ofbiz/ofbiz-framework/trunk/gradlew gradlew
>
> This is only while waiting for the pullAllPluginsSource Gradle task and should not be used in development.
>
> HTH
>
> Jacques
>
>

[Jacques Le Roux]

Le 10/03/2017 à 14:20, Jacques Le Roux a écrit :
> Also I noticed that when framework-trunk tests fail locally no runtime\logs\test-results is created.
Not sure why, but this problem no longer exists when using pullAllPluginsSource

Jacques