Clean problematic files on alibaba workspaces

[Haroon-Khel]

This is a temporary fix to clean workspaces on alibaba machines before builds. Currently both alibaba machines are facing this issue

18:10:26  ERROR: Failed to clean the workspace
18:10:26  jenkins.util.io.CompositeIOException: Unable to delete 'C:\Jenkins\temp'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.
18:10:26  	at jenkins.util.io.PathRemover.forceRemoveDirectoryContents(PathRemover.java:90)
18:10:26  	at hudson.Util.deleteContentsRecursive(Util.java:262)
18:10:26  	at hudson.Util.deleteContentsRecursive(Util.java:251)
18:10:26  	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:743)

This issue has affected other windows boxes, hence the pr #1956, so I am putting a similar fix in for alibaba machines.

Most recent failure on build-alibaba-win2012r2-x64-1 https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-windows-x64-dragonwell/58/console

[M-Davies]

There is a worrying amount of hardcoded deletions here. I wonder if there's a much more efficient cleanup mechanism at the end of builds?

[AdamBrousseau]

Probably related
eclipse-openj9/openj9#10834

I think some new investigation by @jdekonin pointed at long path lengths being the root cause.

[Willsparker]

@Haroon-Khel Can you not just set the workspace variables to C:/workspace/ for the machines? I think that would be covered by: https://github.com/AdoptOpenJDK/openjdk-build/blob/102237341c7f0737f0dd4dc57fcc7e9e3ffe3bd5/pipelines/build/common/openjdk_build_pipeline.groovy#L915
And removes the need for another line

Also, ref: adoptium/infrastructure#1818

[Haroon-Khel]

Good spot @Willsparker. Ill change the workspace to that and run some jobs. Should it be sufficient, ill close this pr

[Haroon-Khel]

Latest run https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-dragonwell/81/console

14:20:19  The recommended git tool is: git
14:20:19  No credentials specified
14:20:19  Cloning the remote Git repository
14:20:19  Cloning repository https://github.com/AdoptOpenJDK/openjdk-build.git
14:20:20  ERROR: Failed to clean the workspace
14:20:20  jenkins.util.io.CompositeIOException: Unable to delete 'C:\workspace'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.
14:20:20  	at jenkins.util.io.PathRemover.forceRemoveDirectoryContents(PathRemover.java:90)

This is while the workspace was C:/workspace/ to test. I also get this error when the workspace is C:\workspace\. I tried both because the rm command in the build scripts uses forward slashes despite it trying to remove a windows directory

[Haroon-Khel]

Ok, I realise that the workspace needs to be C:\workspace\openjdk-build. Having made that change, I get the familiar gradle error

14:26:52  Exception in thread "main" java.io.FileNotFoundException: \cygdrive\c\workspace\openjdk-build\workspace\.gradle\wrapper\dists\gradle-6.5-bin\6nifqtx7604sqp1q6g8wikw7p\gradle-6.5-bin.zip.lck (Access is denied)
14:26:52  	at java.base/java.io.RandomAccessFile.open0(Native Method)
14:26:52  	at java.base/java.io.RandomAccessFile.open(RandomAccessFile.java:345)

Latest run https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-dragonwell/83/console

This may be related to @sxa's comment adoptium/infrastructure#1818 (comment)

[Haroon-Khel]

@M-Davies How can I test this pr? The build jobs do not give a parameter, for example, from which repo to use build scripts

[M-Davies]

run tests

See https://github.com/AdoptOpenJDK/openjdk-build/blob/master/pipelines/build/prTester/README.md for all of our potential tests that run :)

[adoptopenjdk-github-bot]

 PR TESTER RESULT 

❎ Some pipelines failed or the job was aborted! ❎
See the pipeline-build-check below for more information...

[sxa]

Runs ok as per adoptium/infrastructure#1818 (comment)

[M-Davies]

 PR TESTER RESULT 

❎ Some pipelines failed or the job was aborted! ❎
See the pipeline-build-check below for more information...

Failing job was an unrelated aarch64 problem. Windows ran ok

[sxa]

There is a worrying amount of hardcoded deletions here. I wonder if there's a much more efficient cleanup mechanism at the end of builds?

@M-Davies Completely agree - feel free to pick up #2205 ;-) I'd imagine there's a suitable variable we could use instead ...

[sxa]

@Haroon-Khel Does this still need to be in draft in light of all the testing above?