Temurin-build: Dependency build jobs (asmtools & jtreg) are broken

[smlambert]

https://ci.adoptopenjdk.net/view/Dependencies/job/asmtools/ is broken, last good build on Nov 18, started failing Nov 23, 2019.

The downstream jtreg job is also failing.

See http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-December/040326.html for discussion on how to fix (reference to http://hg.openjdk.java.net/code-tools/jtreg/file/c82fc1196801/README for some additional details).

[iignatev]

FWICS, asmtools job failure isn't related to jtreg job failure.
asmtools fails b/c JDK/javac used by ant doesn't support 9 source/target. while jtreg failure seems to be related to an extra check added to jtreg build by deee95d5d8ff, so it's believed that jtreg build script isn't run from jtreg's workspace directory.

[smlambert]

I had not looked closely at the cause, thanks @iignatev for the closer examination and interpretation of the problem, I've updated this issue to not mislead.

[M-Davies]

Taken from a jdk11-windowsx64-hotspot sanity job: https://ci.adoptopenjdk.net/view/Test_openjdk/job/Test_openjdk11_hs_sanity.openjdk_x86-64_windows/100/

23:37:10  downloading dependent third party jars to C:/Users/jenkins/workspace/Test_openjdk11_hs_sanity.openjdk_x86-64_windows/openjdk-tests/\\TKG\\lib
23:37:10  downloading http://central.maven.org/maven2/org/ow2/asm/asm-all/6.0_BETA/asm-all-6.0_BETA.jar
23:37:10  ERROR: sha checksum error.
23:37:10  --> file downloaded to C:/Users/jenkins/workspace/Test_openjdk11_hs_sanity.openjdk_x86-64_windows/openjdk-tests/\\TKG\\lib\asm-all.jar
23:37:10  Expected sha is: 535f141f6c8fc65986a3469839a852a3266d1025,
23:37:10  Actual sha is  : f2f8bdd51f1a5280c7874af519fdf6425431cecd.
23:37:10  Please delete C:/Users/jenkins/workspace/Test_openjdk11_hs_sanity.openjdk_x86-64_windows/openjdk-tests/\\TKG\\lib\asm-all.jar and rerun the program!make: *** [makefile:68: getdependency] Error 255

This may not be related but I thought it would be worth mentioning. All the x32 and x64 windows test pipelines are suffering from this problem. Perhaps a deletion of asm-all.jar and a rerun will clean this up?

[sxa]

@M-Davies The workspace is wiped at the end of each run. That is a real problem

[sxa]

@smlambert I've run the job that @M-Davies mentioned with the keep workspace option, and the asm-all.jar that's left in there looks ok and has the "expected" sha when I run shasum on it, which suggests there's something wrong in whatever is checking the checksum (Based on the run in https://ci.adoptopenjdk.net/view/Test_openjdk/job/Test_openjdk11_hs_sanity.openjdk_x86-64_windows/106/) - is there something odd in the way the checksums are being calculated?

@M-Davies When you say "All the x32 and x64 windows test pipelines are suffering from this problem." what do you mean - it looks like that job has passed a few times - it's likely only an issue on the packet windows system.

[sxa]

Strawberry perl isn't giving the same results as the shasum command, but cygwin perl is ... . oO(That's odd)

I've removed Strawberry perl from that machine for now and will see if there are any negatives to doing so ...

[sxa]

@iignatev Is JDK9+ support a new thing that's been added recently?

[sxa]

Adjusted to export JAVA_HOME=/home/jenkins/jdk-11.0.5+10 and manually installed adoptopenjdk11 in that location.

[sxa]

For jtreg the build-all.sh appears to need to be run from the root of the repository (i.e. the plance with .hg in it), therefore adjusting job to run make/build-all.sh instead of cd make then ./build-all.sh otherwise it fails to detect the SCM in use ...

```
++ get_scm_type
++ '[' -d .hg ']'
++ '[' -d .git ']'
++ echo 'Error: unrecognized repository, it must be Git or Mercurial'
Error: unrecognized repository, it must be Git or Mercurial
++ exit 1

• SCM_TYPE=
  Build step 'Execute shell' marked build as failure
  ``

[sxa]

All issues now fixed ...

[M-Davies]

@sxa555 That particular problem seems to be intermittent. Of the 8 pipelines that ran since then, 4 failed with this error (on jdk11-windowsx64-hotspot at least). At the time of my original comment, all of the windows pipelines for jdk11 and 13 were failing with this error (now a mix between passing and failing with an unexpected sha error). I did double check and it does appear that the failure is unique to the packet windows system

[sxa]

@M-Davies That definitely sounds like a separate issue from the title of this then :-)

[M-Davies]

JTReg and asm look to be ok now. Can this issue be closed?