OK, done. It's pretty noisy, so we will probably want to remove it as soon as we decide if it gives us any clues about the Jenkins failures or not.
thanks, bryan On Tue, May 15, 2018 at 5:41 AM, Rick Hillegas <rick.hille...@gmail.com> wrote: > On 5/14/18 8:06 PM, Bryan Pendleton wrote: >> >> For now, perhaps we should just open a bug in JIRA so we can track this? >> >> As to how to get more visibility, I think that we could perhaps add a call >> to >> 'echoproperties' in our build.xml and then our Jenkins jobs would echo >> their system configuration to the output logs. >> >> Then we could see if we could spot anything unusual in the configuration >> of the Jenkins slaves that run these jobs (i.e., which operating system, >> which compiler, etc.) >> >> I.e., something like: > > This sounds useful. +1 > >> >> Index: build.xml >> =================================================================== >> --- build.xml (revision 1831532) >> +++ build.xml (working copy) >> @@ -44,6 +44,8 @@ >> </not> >> </condition> >> >> +<echoproperties/> >> + >> <!-- Targets --> >> >> <target >> >> >> >> On Mon, May 14, 2018 at 4:52 PM, Rick Hillegas <rick.hille...@gmail.com> >> wrote: >>> >>> I have tried running the unit tests under ant via the junit-core target. >>> But >>> I am unable to reproduce the error we are seeing in the Jenkins builds. >>> One >>> of the tests which is failing (InternationalConnectSimpleDSTest) is >>> trying >>> to boot a database whose name is a Chinese character. The database >>> directory >>> is the file which incurs the permissions exception. Maybe Jenkins is >>> running >>> on a platform which doesn't support Chinese characters in directory >>> names? I >>> don't see any bugs in this area. The closest bug I could find is >>> DERBY-728, >>> which was a problem with the network protocol layer. I don't know how to >>> get >>> more visibility into the error. I tripped over a 404 error when I clicked >>> on >>> the artifacts link of the test failure. >>> >>> >>> On 5/13/18 10:07 AM, Bryan Pendleton wrote: >>>> >>>> Hi Rick, >>>> >>>> On both the environments I have available (Windows 10 / JDK 9.0.4 and >>>> Fedora / JDK 9.0.1) all those tests passed without issue. >>>> >>>> Eyeballing the details of the Jenkins run in >>>> >>>> >>>> https://builds.apache.org/blue/organizations/jenkins/Derby-trunk-suites.All/detail/Derby-trunk-suites.All/169/tests/ >>>> it certainly seems to me like the issue involves international >>>> characters >>>> in permissions files. All of the failed tests complain about access >>>> denied >>>> errors for java.io.FilePermission on file paths which contain >>>> filename components in international character sets. >>>> >>>> Maybe that's a clue as to what's different about the Jenkins slave? >>>> >>>> Also, and I think unrelated, did you happen to see the errors in >>>> >>>> >>>> https://builds.apache.org/job/Derby-trunk/2554/display/redirect?page=changes >>>> >>>> Those errors are in the 'publishedapi' target, and the message is: >>>> >>>> install_packagelists: >>>> [mkdir] Created dir: >>>> <https://builds.apache.org/job/Derby-trunk/ws/trunk/packageListLoc-se-8> >>>> [mkdir] Created dir: >>>> >>>> <https://builds.apache.org/job/Derby-trunk/ws/trunk/packageListLoc-j2ee-7> >>>> [get] Getting: >>>> http://docs.oracle.com/javase/8/docs/api/package-list >>>> [get] To: >>>> >>>> >>>> <https://builds.apache.org/job/Derby-trunk/ws/trunk/packageListLoc-se-8/package-list> >>>> [get] http://docs.oracle.com/javase/8/docs/api/package-list >>>> permanently moved to >>>> https://docs.oracle.com/javase/8/docs/api/package-list >>>> >>>> BUILD FAILED >>>> <https://builds.apache.org/job/Derby-trunk/ws/trunk/build.xml>:999: >>>> The following error occurred while executing this line: >>>> <https://builds.apache.org/job/Derby-trunk/ws/trunk/build.xml>:1027: >>>> Redirection detected from http to https. Protocol switch unsafe, not >>>> allowed. >>>> >>>> Looking at the value of 'javasedoc.url' in our build.xml file: >>>> >>>> <property name="javasedoc.url" >>>> value="http://docs.oracle.com/javase/8/docs/api"/> >>>> >>>> two things occur to me: >>>> >>>> 1) Should we change it from java 8 to java 9? >>>> >>>> 2) Can we simply change the url to specify https rather than http? If >>>> that works, >>>> then we probably have to do that for j2eedoc.url also? >>>> >>>> Thanks again for all the help getting these cleaned up, I will be >>>> happier >>>> if >>>> we are getting clean runs from our Jenkins system. >>>> >>>> bryan >>>> >
