Enable Windows test build

[smlambert]

Now that we have a Windows test machine, we should enable a openjdk_test_x86-64_windows build triggered from successful completion of openjdk_build_x86-64_windows that runs all the tests.

[sophia-guo]

Tests are enabled:
https://ci.adoptopenjdk.net/view/OpenJDK%20tests/job/openjdk_test_x86-64_windows/144/console

However it has taken 4 days to run all regression tests on windows( may not even finished). We will probably need to rethink the schedule of test build on windows or set up a different test group on windows? Will stop the build trigger for now.

[karianna]

4 days seems a little odd! Are tests timing out? Or is each test just taking a long time (which might just be a CPU / RAM issue we can sort).

[gdams]

do we know if the tests are using multiple cores? the windows machines is 4CPU and 8GB ram. I hope that we will be able to get some more powerful windows boxes in the near future

[sophia-guo]

@we have timeoutFactor if timeout test will finish as a failure. I haven't checked out if some tests require multiple cores. Currently we haven't set up concurrency factor for jtreg tests. Some jtreg tests cannot be run concurrently. If we want to use concurrency factor we need to figure out which test can run concurrently and which can't.

From console output I could see tests have run for 9 hours and got:
06:04:00 --------------------------------------------------
Resuming build at Thu Jun 01 22:23:34 CEST 2017 after Jenkins restart
Waiting to resume part of openjdk_test_x86-64_windows #144: ???
Waiting to resume part of openjdk_test_x86-64_windows #144: test-packet-x64-windows-2012r2-1 is offline
Waiting to resume part of openjdk_test_x86-64_windows #144: test-packet-x64-windows-2012r2-1 is offline
Ready to run at Thu Jun 01 22:23:51 CEST 2017
Aborted by George Adams

Machine is restarted?

[sophia-guo]

Enable concurrency. Test hours on linux drops from 8 hours to 5 hours. Haven't got data on Windows.

It seems when window test machine is offline( either by regular jenkins restart or unknown reason) the next build will continually fail at first step:
[Pipeline] End of Pipeline
java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\openjdk_test_x86-64_windows\openjdk-test\OpenJDK_Playlist\openjdk-jdk8u\jdk\test\sun\management\windows\revokeall.exe

https://ci.adoptopenjdk.net/view/OpenJDK%20tests/job/openjdk_test_x86-64_windows/151/console

[karianna]

@sophia-guo Can you log into that box? I'm guessing that either .exe files have special permissioning or that we're not running the delete as an Administrator.

[sophia-guo]

I only have jenkins permission.

All files are generated by jenkins. And delete as jenkins.
C:\Users\jenkins\workspace\openjdk_test_x86-64_windows\openjdk-test\OpenJDK_Play
list\openjdk-jdk8u\jdk\test\sun\management\windows>ls -l
total 32
-rw-rw----+ 1 jenkins None 32768 Jun 6 16:27 revokeall.exe

C:\Users\jenkins\workspace\openjdk_test_x86-64_windows\openjdk-test\OpenJDK_Play
list\openjdk-jdk8u\jdk\test\sun\management\windows>ls -l
total 32
-rw-rw----+ 1 jenkins None 32768 Jun 6 16:27 revokeall.exe

@bblondin jenkins job files group are "None", is this expected? Thanks.

[bblondin]

@sophia-guo Windows doesn't support group permissions the same way that *nix does. this is normal.
are you experiencing an issue?

[sophia-guo]

Yes, Brad.

It seems when window test machine is offline( either by regular jenkins restart or unknown reason) the next build will continually fail at first step:
[Pipeline] End of Pipeline
java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\openjdk_test_x86-64_windows\openjdk-test\OpenJDK_Playlist\openjdk-jdk8u\jdk\test\sun\management\windows\revokeall.exe

https://ci.adoptopenjdk.net/view/OpenJDK%20tests/job/openjdk_test_x86-64_windows/151/console

[bblondin]

@sophia-guo Have you considered telling jenkins to delete the workspace before the build and/or afterwards.

https://wiki.jenkins.io/display/JENKINS/Workspace+Cleanup+Plugin

[sophia-guo]

@bblondin yes, for pipeline we use the feature " Wipe out repository & force clone".

[smlambert]

Brad did some more digging and we see now that the permissions of the revokeAll.exe file is incorrect straight out of the gate.

In our pipeline, we do a "git clone -b dev https://github.com/AdoptOpenJDK/openjdk-jdk8u.git".
Brad tried it manually, and when you look at the properties of the openjdk-jdk8u\jdk\test\sun\management\windows\revokeall.exe file, it pops up a message window that states the permissions are not correct on that file and it may cause issues.

We can try to regenerate that file and see if we can get the proper permissions, instructions for regenerating the file are here: https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/dev/jdk/test/sun/management/windows/README

[bblondin]

Looking into this deeper...
manually cloning this repo using GIT Bash doesn't have this issue... use CMD.exe does. (which is what Jenkins uses)

GIT Bash: git --verion: 1.9.4.msysgit.0
vs
CMD.exe: git --version: 2.12.3 (which is from cygwin)

calling GIT Bash's git from CMD.exe works
C:\Users\jenkins\AppData\Local\Programs\Git\bin\git.exe clone -b dev https://github.com/AdoptOpenJDK/openjdk-jdk8u.git

I've renamed cygwin's git.exe to git.exe.bbb and added C:\Users\jenkins\AppData\Local\Programs\Git\bin\ to the end of the path.

@smlambert could you try the test again please

[gdams]

@bblondin you should be able to specify the tool location for git in the machine configuration page. That way jenkins will always use the version specified there

[sophia-guo]

Configuration updated: adoptium/infrastructure#23
Similar issue stays.

https://ci.adoptopenjdk.net/view/OpenJDK%20tests/job/openjdk_test_x86-64_windows/231/console

[tellison]

Is this test running ok when you logon to the machine directly, and only failing when run via Jenkins?

[sophia-guo]

I believe I tried before got same issue with former configuration as Jenkins user. I will try with configuration updated to see if it's ok running directly on machine.

[sophia-guo]

Log in windows machine as jenkins user.
GIT Bash: git --verion: 1.9.4.msysgit.0
CMD.exe: git --verion: 1.9.4.msysgit.0

Using CMD.exe , git clone, running tests, wipe out tests meterials , all works fine.

Current problem running by jenkins jenkins user cannot wipe out the workspace created by jenkins user itself.

[sophia-guo]

As I mentioned in former comment " it happened when window test machine is offline( either by regular jenkins restart or unknown reason) the next build will continually fail at first step "wipe out".

We need someone with root/admin permission to wipe out the WS and see updated configuration works or not.

[sophia-guo]

No this issues in recently build. adoptium/infrastructure#23 closed. Close this one too.