Temurin-build: Failed to copy artifacts filter spec fix #1830

[douph1]

About this failed build https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-windows-x64-openj9-windowsXL/364/

06:44:54  Copied 0 artifacts from "build-scripts » release » create_installer_windows" build number 4410
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] echo
06:44:54  Execution error: Failed to copy artifacts from build-scripts/release/create_installer_windows with filter: wix/ReleaseDir/OpenJDK*jdk_*_windows_*.msi

https://ci.adoptopenjdk.net/job/build-scripts/job/release/job/create_installer_windows/4410/console
had produce : OpenJDK11U-jdk_x64_windows_openj9_windowsXL_2020-06-05-23-31.msi

At the begining I was thinking the filter was bad because I have only see _windowsXL doesn't match _windows_ .. but there is a _windows_ before _windowsXL .. so the filter must have been matched.

Why OpenJDK*jdk_*_windows_*.msi havn't matched OpenJDK11U-jdk_x64_windows_openj9_windowsXL_2020-06-05-23-31.msi

seeing copyArtifacts filter doc : https://www.jenkins.io/doc/pipeline/steps/copyartifact/

See the @includes of Ant fileset for the exact format.

I have juste tested with ant :
```

`ant`

```Buildfile: /home/doussot/apologic/testant/build.xml

testfilter:
     [copy] Copying 1 file to /tmp/dst
     [copy] Copying /tmp/src/wix/ReleaseDir/OpenJDK11U-jdk_x64_windows_openj9_windowsXL_2020-06-05-23-31.msi to /tmp/dst/wix/ReleaseDir/OpenJDK11U-jdk_x64_windows_openj9_windowsXL_2020-06-05-23-31.msi

BUILD SUCCESSFUL
Total time: 0 seconds

Either copyartifact don't exactly use exact filter format as Ant fileset @includes
either the filter was not the problem.

[douph1]

I thinking it must have matched like this when there was the first error : OpenJDK(11U-)jdk_(x64)_windows_(openj9_windowsXL_2020-06-05-23-31).msi

[M-Davies]

For the record, the failed match was on build-azure-win2012r2-x64-2. Later builds seem to be doing better, one on the same machine which passed.

@karianna was changing up how we copy artefacts from build to build yesterday. It's possible this may have fixed it. I'll keep an eye on it over the next week to see if this reoccurs

[M-Davies]

Later builds look ok. I'm going to put this under "fixed by copy artifact" changes. This can always be reopened if we see it again

[M-Davies]

This is strange. It seems to be an intermittent problem I'm seeing in the build scripts.

I've seen two instances of this in the nightlies last night

• https://ci.adoptopenjdk.net/view/Failing%20Builds/job/build-scripts/job/jobs/job/jdk14u/job/jdk14u-windows-x64-openj9/105/console (Installer ran green) failed with this

04:37:24  Execution error: Failed to copy artifacts from build-scripts/release/create_installer_windows with filter: wix/ReleaseDir/OpenJDK*jdk_*_windows*.msi

But a build two days before that, passed https://ci.adoptopenjdk.net/view/Failing%20Builds/job/build-scripts/job/jobs/job/jdk14u/job/jdk14u-windows-x64-openj9/103/console

• https://ci.adoptopenjdk.net/view/Failing%20Builds/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-windows-x64-openj9-windowsXL/371/console (Installer ran green again) failed with the same error as above. Again, the build two days before passed https://ci.adoptopenjdk.net/view/Failing%20Builds/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-windows-x64-openj9-windowsXL/369/

Keeping in mind my changes to windows installer went in over a week ago (except for https://github.com/AdoptOpenJDK/openjdk-build/pull/1830), I don't think it's due to that.

A cause could be the filter path. I'm seeing

Done Adding Additional Store
Successfully signed: ReleaseDir\OpenJDK11-jdk_x64_windows_openj9-11.0.8.6.msi

Done Adding Additional Store
Successfully signed: ReleaseDir\OpenJDK11-jdk_x64_windows_openj9-11.0.8.6.msi

in https://ci.adoptopenjdk.net/job/build-scripts/job/release/job/create_installer_windows/4565/console and

Done Adding Additional Store
Successfully signed: ReleaseDir\OpenJDK14-jdk_x64_windows_openj9-14.0.1.7.msi

Done Adding Additional Store
Successfully signed: ReleaseDir\OpenJDK14-jdk_x64_windows_openj9-14.0.1.7.msi

in https://ci.adoptopenjdk.net/job/build-scripts/job/release/job/create_installer_windows/4563/console (the same installer jobs ran for the builds I linked above).

So to resolve this, I'm guessing I would need to update the filter to be ReleaseDir/OpenJDK*jdk_*_windows*.msi but that doesn't explain why other jobs, like this one manage to copy the artifacts over fine.

@douph1 Any ideas?

[M-Davies]

I'm testing the theory I mentioned above with a temp PR https://github.com/AdoptOpenJDK/openjdk-build/pull/1856

[karianna]

Also see #1858

[M-Davies]

I'm testing the theory I mentioned above with a temp PR #1856

Test theory wasn't successful

[M-Davies]

https://ci.adoptopenjdk.net/view/Failing%20Builds/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-hotspot/641/console
https://ci.adoptopenjdk.net/view/Failing%20Builds/job/build-scripts/job/jobs/job/jdk14u/job/jdk14u-windows-x86-32-hotspot/109/console

22:35:58  Copied 0 artifacts from "build-scripts » release » create_installer_windows" build number 4769
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] echo
22:35:58  Execution error: Failed to copy artifacts from build-scripts/release/create_installer_windows with filter: wix/ReleaseDir/*

[karianna]

Is that because of permissions or something else though...

[douph1]

I have see lot of this error "Failed to copy artifacts" on internet with a stacktrace .. I don't know how but did you think we can print stacktrace together with the error message ?

[M-Davies]

@douph1 It doesn't look like it is printing the full trace 😭
https://ci.adoptopenjdk.net/view/Failing%20Builds/job/build-scripts/job/jobs/job/jdk14u/job/jdk14u-windows-x64-openj9/116/console

08:18:25  Scheduling project: build-scripts » release » create_installer_windows
08:18:33  Starting building: build-scripts » release » create_installer_windows #4896
[Pipeline] copyArtifacts
08:24:18  Copied 0 artifacts from "build-scripts » release » create_installer_windows" build number 4896
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] echo
08:24:18  Execution error: hudson.AbortException: Failed to copy artifacts from build-scripts/release/create_installer_windows with filter: wix/ReleaseDir/*

[douph1]

I'm not a groovy export, I have just seen this syntax in the script using ${e} and I don't have made my homeworks :(
Maybe context.println "Execution error: " + e.printStackTrace()
is better ?

[M-Davies]

It's worth a shot 🤷

[douph1]

wait
see https://issues.apache.org/jira/browse/GROOVY-3947
https://issues.jenkins-ci.org/browse/JENKINS-44808

System.err of the Jenkins JVM is not the same as the build log.

Pipeline scripts by default run in a sandbox.

but fails in a Jenkinsfile with Scripts not permitted to use method java.lang.Throwable getStackTrace

We must first know if

this to use this "unsecure" function to work in a jenkinsfile script or pipeline dsl library,

[douph1]

it will be harder after next jenkins update to see stactrace for non-administrator :

https://www.jenkins.io/changelog-stable/
Suppress error stack traces for non-administrator users as core capability. (issue 60410)
https://issues.jenkins-ci.org/browse/JENKINS-60410
Hopefully, this is probably not the job stacktrace
Internal stack traces exposed to users

[M-Davies]

https://ci.adoptopenjdk.net/view/Failing%20Builds/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-windows-x64-openj9/649/console

05:13:33  Copied 0 artifacts from "build-scripts » release » create_installer_windows" build number 5075
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] echo
05:13:33  Execution error: hudson.AbortException: Failed to copy artifacts from build-scripts/release/create_installer_windows with filter: wix/ReleaseDir/*
[Pipeline] }
[Pipeline] // timeout
[Pipeline] }
[Pipeline] // timestamps
[Pipeline] End of Pipeline
ERROR: Failed to copy artifacts from build-scripts/release/create_installer_windows with filter: wix/ReleaseDir/*

Still no stacktrace unfortunately. Could we perhaps roll it back and just do printstacktrace and get admin permission to do so?

[M-Davies]

Renamed to make it more appropriate as this no longer a question

[M-Davies]

I suspect @andrew-m-leonard fixed this when he increased the job retention as I haven't seen this for a while now. I'll close this but we can always reopen if it reappears