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:
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
>>
>
