Re: Gradle Tool Failed Download

2019-09-25 Thread Sverre Moe
I thought about using "Extract *.zip/*.tar.gz instead, and pointing it to a 
custom Gradle distribution at an inhouse URL.

However the gradle distribution is unpackaged into a second subdirectory:
/jenkins/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.6/
gradle-5.6.1
While the tool gives me the directory:
/jenkins/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.6
And I expect gradle executable should be:
${gradleTool}/bin/gradle

Unpacking 
https://nexus.company.no:8443/repository/gradle-distributions/gradle-5.6.1-bin.zip
 

 to 
/home/build/jenkins/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.6 
on sles12.3-x86_64_4


+ 
/home/build/jenkins/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.6/bin/gradle
 -version
/home/build/jenkins/workspace/pipeline-tests/pipeline-gradle-tools@tmp/durable-81b2542a/script.sh:
 line 1: 
/home/build/jenkins/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.6/bin/gradle:
 No such file or directory



I have been trying to use a "Shell command" instead, but am having 
difficulty scripting a quick no-op if the tool is already installed. 
Getting none of the Bash magic for checking empty directory to work.


onsdag 25. september 2019 11.38.23 UTC+2 skrev Sverre Moe følgende:
>
> There is no Exception thrown when running that in script console.
>
> Result: PK 
> A 
> gradle-5.6.2/ PK 
> AĘ|H !gradle-5.6.2/getting-start
>
> Same for Maven
> hudson.ProxyConfiguration.getInputStream(new URL("
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.zip;)).text.substring(0,
>  
> 100)
>
> Result: PK  
>  B� O apache-maven-3.6.2/PK  
>  =� O apache-maven-3.6.2/li
>
>
>
> onsdag 25. september 2019 11.13.13 UTC+2 skrev Daniel Beck følgende:
>>
>> Run the following in the Jenkins script console:
>>
>> hudson.ProxyConfiguration.getInputStream(new URL("
>> https://services.gradle.org/distributions/gradle-5.6.2-bin.zip;)).text.substring(0,
>>  
>> 100)
>>
>> Note that this loads the entire downloaded file, if successful, into 
>> memory, so not quite production quality code ;-)
>>
>> Replace the URL as needed to try whatever URLs are listed as being 
>> downloaded with the different installers. The expectation for zip files is 
>> that the output starts with "PK". If the same exception gets thrown for 
>> Groovy/Gradle, while Maven works, it's SSL after all. (Gradle Wrapper would 
>> run probably on a different machine, with different JRE, so that doesn't 
>> tell you much.)
>>
>>
>> On Wed, Sep 25, 2019 at 10:59 AM Sverre Moe  wrote:
>>
>>> Both the MavenInstaller and GradleInstaller are very similar
>>>
>>> public static class MavenInstaller extends DownloadFromUrlInstaller {
>>> public class GradleInstaller extends DownloadFromUrlInstaller {
>>>
>>> I thought perhaps they used different implementation, and that was the 
>>> reason for why GradleInstaller had problems.
>>>
>>> https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/tasks/Maven.java
>>>
>>> https://github.com/jenkinsci/gradle-plugin/blob/master/src/main/java/hudson/plugins/gradle/GradleInstaller.java
>>>
>>>
>>> Both Jenkins Server and Build agents are behind a firewall. The Jenkins 
>>> has proxy configured, but the build agents do not have any proxy configured.
>>> I have same problem using Gradle wrapper, but as mentioned earlier here 
>>> gradle wrapper works if I configure proxy properties.
>>>
>>>
>>> onsdag 25. september 2019 10.41.32 UTC+2 skrev Sverre Moe følgende:

 Which projects has the source code for the Maven, Gradle and Groovy 
 Tool installers? I want to have a check to see if there is something to be 
 done on the Gradle and Groovy tool installers.

 onsdag 25. september 2019 10.30.17 UTC+2 skrev Sverre Moe følgende:
>
> The Gradle tool installer is not the only tool having this problem. I 
> am getting the same SSL problem with Groovy tool installers.
>
> Makes me wonder, what does the maven tool installer do different than 
> the Gradle and Groovy tool installers.
>
> mandag 23. september 2019 22.26.10 UTC+2 skrev Sverre Moe følgende:
>>
>> I have gotten this problem both for Jenkins running Java 8u221 and 
>> Java 11.0.4+11. The latest for both 8 and 11.
>>
>> Maven tool download works just fine, using the same JDK, so why would 
>> the gradle installer have a problem?
>>
>> I do not like to check in the gradle wrapper files into version 
>> control, but considering it might ease new developers I am beginning to 
>> lean into it.
>>
>> mandag 23. september 2019 18.25.04 UTC+2 skrev Jan Monterrubio 
>> følgende:
>>>
>>> I’ve always relied on projects supplying the gradle wrapper 
>>> instead... that might be a good alternative if you can’t upgrade the JRE
>>>
>>> On Mon, Sep 

Re: Gradle Tool Failed Download

2019-09-25 Thread Sverre Moe
There is no Exception thrown when running that in script console.

Result: PK  
  A 
gradle-5.6.2/ PK  
  AĘ|H !gradle-5.6.2/getting-start

Same for Maven
hudson.ProxyConfiguration.getInputStream(new 
URL("https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.zip;)).text.substring(0,
 
100)

Result: PK  
 B� O apache-maven-3.6.2/PK  
 =� O apache-maven-3.6.2/li



onsdag 25. september 2019 11.13.13 UTC+2 skrev Daniel Beck følgende:
>
> Run the following in the Jenkins script console:
>
> hudson.ProxyConfiguration.getInputStream(new URL("
> https://services.gradle.org/distributions/gradle-5.6.2-bin.zip;)).text.substring(0,
>  
> 100)
>
> Note that this loads the entire downloaded file, if successful, into 
> memory, so not quite production quality code ;-)
>
> Replace the URL as needed to try whatever URLs are listed as being 
> downloaded with the different installers. The expectation for zip files is 
> that the output starts with "PK". If the same exception gets thrown for 
> Groovy/Gradle, while Maven works, it's SSL after all. (Gradle Wrapper would 
> run probably on a different machine, with different JRE, so that doesn't 
> tell you much.)
>
>
> On Wed, Sep 25, 2019 at 10:59 AM Sverre Moe  > wrote:
>
>> Both the MavenInstaller and GradleInstaller are very similar
>>
>> public static class MavenInstaller extends DownloadFromUrlInstaller {
>> public class GradleInstaller extends DownloadFromUrlInstaller {
>>
>> I thought perhaps they used different implementation, and that was the 
>> reason for why GradleInstaller had problems.
>>
>> https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/tasks/Maven.java
>>
>> https://github.com/jenkinsci/gradle-plugin/blob/master/src/main/java/hudson/plugins/gradle/GradleInstaller.java
>>
>>
>> Both Jenkins Server and Build agents are behind a firewall. The Jenkins 
>> has proxy configured, but the build agents do not have any proxy configured.
>> I have same problem using Gradle wrapper, but as mentioned earlier here 
>> gradle wrapper works if I configure proxy properties.
>>
>>
>> onsdag 25. september 2019 10.41.32 UTC+2 skrev Sverre Moe følgende:
>>>
>>> Which projects has the source code for the Maven, Gradle and Groovy Tool 
>>> installers? I want to have a check to see if there is something to be done 
>>> on the Gradle and Groovy tool installers.
>>>
>>> onsdag 25. september 2019 10.30.17 UTC+2 skrev Sverre Moe følgende:

 The Gradle tool installer is not the only tool having this problem. I 
 am getting the same SSL problem with Groovy tool installers.

 Makes me wonder, what does the maven tool installer do different than 
 the Gradle and Groovy tool installers.

 mandag 23. september 2019 22.26.10 UTC+2 skrev Sverre Moe følgende:
>
> I have gotten this problem both for Jenkins running Java 8u221 and 
> Java 11.0.4+11. The latest for both 8 and 11.
>
> Maven tool download works just fine, using the same JDK, so why would 
> the gradle installer have a problem?
>
> I do not like to check in the gradle wrapper files into version 
> control, but considering it might ease new developers I am beginning to 
> lean into it.
>
> mandag 23. september 2019 18.25.04 UTC+2 skrev Jan Monterrubio 
> følgende:
>>
>> I’ve always relied on projects supplying the gradle wrapper 
>> instead... that might be a good alternative if you can’t upgrade the JRE
>>
>> On Mon, Sep 23, 2019 at 05:37 Daniel Beck  
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 23, 2019 at 2:28 PM Sverre Moe  
>>> wrote:
>>>
 ERROR: Failed to download 
 https://services.gradle.org/distributions/gradle-5.6.2-bin.zip from 
 agent; will retry from master

 sun.security.provider.certpath.SunCertPathBuilderException: unable to 
 find valid certification path to requested target



 Which makes me believe that the Gradle tool does not use Jenkins 
 Proxy settings, while Maven tools does use it.

>>>
>>> The error means it's an SSL issue. If you're on an old JRE, update 
>>> it. 
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to jenkins...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" 

Re: Gradle Tool Failed Download

2019-09-25 Thread Daniel Beck
Run the following in the Jenkins script console:

hudson.ProxyConfiguration.getInputStream(new URL("
https://services.gradle.org/distributions/gradle-5.6.2-bin.zip;)).text.substring(0,
100)

Note that this loads the entire downloaded file, if successful, into
memory, so not quite production quality code ;-)

Replace the URL as needed to try whatever URLs are listed as being
downloaded with the different installers. The expectation for zip files is
that the output starts with "PK". If the same exception gets thrown for
Groovy/Gradle, while Maven works, it's SSL after all. (Gradle Wrapper would
run probably on a different machine, with different JRE, so that doesn't
tell you much.)


On Wed, Sep 25, 2019 at 10:59 AM Sverre Moe  wrote:

> Both the MavenInstaller and GradleInstaller are very similar
>
> public static class MavenInstaller extends DownloadFromUrlInstaller {
> public class GradleInstaller extends DownloadFromUrlInstaller {
>
> I thought perhaps they used different implementation, and that was the
> reason for why GradleInstaller had problems.
>
> https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/tasks/Maven.java
>
> https://github.com/jenkinsci/gradle-plugin/blob/master/src/main/java/hudson/plugins/gradle/GradleInstaller.java
>
>
> Both Jenkins Server and Build agents are behind a firewall. The Jenkins
> has proxy configured, but the build agents do not have any proxy configured.
> I have same problem using Gradle wrapper, but as mentioned earlier here
> gradle wrapper works if I configure proxy properties.
>
>
> onsdag 25. september 2019 10.41.32 UTC+2 skrev Sverre Moe følgende:
>>
>> Which projects has the source code for the Maven, Gradle and Groovy Tool
>> installers? I want to have a check to see if there is something to be done
>> on the Gradle and Groovy tool installers.
>>
>> onsdag 25. september 2019 10.30.17 UTC+2 skrev Sverre Moe følgende:
>>>
>>> The Gradle tool installer is not the only tool having this problem. I am
>>> getting the same SSL problem with Groovy tool installers.
>>>
>>> Makes me wonder, what does the maven tool installer do different than
>>> the Gradle and Groovy tool installers.
>>>
>>> mandag 23. september 2019 22.26.10 UTC+2 skrev Sverre Moe følgende:

 I have gotten this problem both for Jenkins running Java 8u221 and Java
 11.0.4+11. The latest for both 8 and 11.

 Maven tool download works just fine, using the same JDK, so why would
 the gradle installer have a problem?

 I do not like to check in the gradle wrapper files into version
 control, but considering it might ease new developers I am beginning to
 lean into it.

 mandag 23. september 2019 18.25.04 UTC+2 skrev Jan Monterrubio følgende:
>
> I’ve always relied on projects supplying the gradle wrapper instead...
> that might be a good alternative if you can’t upgrade the JRE
>
> On Mon, Sep 23, 2019 at 05:37 Daniel Beck  wrote:
>
>>
>>
>> On Mon, Sep 23, 2019 at 2:28 PM Sverre Moe  wrote:
>>
>>> ERROR: Failed to download 
>>> https://services.gradle.org/distributions/gradle-5.6.2-bin.zip from 
>>> agent; will retry from master
>>>
>>> sun.security.provider.certpath.SunCertPathBuilderException: unable to 
>>> find valid certification path to requested target
>>>
>>>
>>>
>>> Which makes me believe that the Gradle tool does not use Jenkins
>>> Proxy settings, while Maven tools does use it.
>>>
>>
>> The error means it's an SSL issue. If you're on an old JRE, update
>> it.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to jenkins...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/a8ae71dc-3515-499c-a038-26a80eebc3a0%40googlegroups.com
> 
> .
>


-- 

Daniel Beck
Senior Software Engineer
CloudBees, Inc.

[image: CloudBees-Logo.png]

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop 

Re: Gradle Tool Failed Download

2019-09-25 Thread Sverre Moe
Both the MavenInstaller and GradleInstaller are very similar

public static class MavenInstaller extends DownloadFromUrlInstaller {
public class GradleInstaller extends DownloadFromUrlInstaller {

I thought perhaps they used different implementation, and that was the 
reason for why GradleInstaller had problems.
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/tasks/Maven.java
https://github.com/jenkinsci/gradle-plugin/blob/master/src/main/java/hudson/plugins/gradle/GradleInstaller.java


Both Jenkins Server and Build agents are behind a firewall. The Jenkins has 
proxy configured, but the build agents do not have any proxy configured.
I have same problem using Gradle wrapper, but as mentioned earlier here 
gradle wrapper works if I configure proxy properties.


onsdag 25. september 2019 10.41.32 UTC+2 skrev Sverre Moe følgende:
>
> Which projects has the source code for the Maven, Gradle and Groovy Tool 
> installers? I want to have a check to see if there is something to be done 
> on the Gradle and Groovy tool installers.
>
> onsdag 25. september 2019 10.30.17 UTC+2 skrev Sverre Moe følgende:
>>
>> The Gradle tool installer is not the only tool having this problem. I am 
>> getting the same SSL problem with Groovy tool installers.
>>
>> Makes me wonder, what does the maven tool installer do different than the 
>> Gradle and Groovy tool installers.
>>
>> mandag 23. september 2019 22.26.10 UTC+2 skrev Sverre Moe følgende:
>>>
>>> I have gotten this problem both for Jenkins running Java 8u221 and Java 
>>> 11.0.4+11. The latest for both 8 and 11.
>>>
>>> Maven tool download works just fine, using the same JDK, so why would 
>>> the gradle installer have a problem?
>>>
>>> I do not like to check in the gradle wrapper files into version control, 
>>> but considering it might ease new developers I am beginning to lean into it.
>>>
>>> mandag 23. september 2019 18.25.04 UTC+2 skrev Jan Monterrubio følgende:

 I’ve always relied on projects supplying the gradle wrapper instead... 
 that might be a good alternative if you can’t upgrade the JRE

 On Mon, Sep 23, 2019 at 05:37 Daniel Beck  wrote:

>
>
> On Mon, Sep 23, 2019 at 2:28 PM Sverre Moe  wrote:
>
>> ERROR: Failed to download 
>> https://services.gradle.org/distributions/gradle-5.6.2-bin.zip from 
>> agent; will retry from master
>>
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to 
>> find valid certification path to requested target
>>
>>
>>
>> Which makes me believe that the Gradle tool does not use Jenkins 
>> Proxy settings, while Maven tools does use it.
>>
>
> The error means it's an SSL issue. If you're on an old JRE, update it. 
>
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to jenkins...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com
>  
> 
> .
>


-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/a8ae71dc-3515-499c-a038-26a80eebc3a0%40googlegroups.com.


Re: Gradle Tool Failed Download

2019-09-25 Thread Sverre Moe
Which projects has the source code for the Maven, Gradle and Groovy Tool 
installers? I want to have a check to see if there is something to be done 
on the Gradle and Groovy tool installers.

onsdag 25. september 2019 10.30.17 UTC+2 skrev Sverre Moe følgende:
>
> The Gradle tool installer is not the only tool having this problem. I am 
> getting the same SSL problem with Groovy tool installers.
>
> Makes me wonder, what does the maven tool installer do different than the 
> Gradle and Groovy tool installers.
>
> mandag 23. september 2019 22.26.10 UTC+2 skrev Sverre Moe følgende:
>>
>> I have gotten this problem both for Jenkins running Java 8u221 and Java 
>> 11.0.4+11. The latest for both 8 and 11.
>>
>> Maven tool download works just fine, using the same JDK, so why would the 
>> gradle installer have a problem?
>>
>> I do not like to check in the gradle wrapper files into version control, 
>> but considering it might ease new developers I am beginning to lean into it.
>>
>> mandag 23. september 2019 18.25.04 UTC+2 skrev Jan Monterrubio følgende:
>>>
>>> I’ve always relied on projects supplying the gradle wrapper instead... 
>>> that might be a good alternative if you can’t upgrade the JRE
>>>
>>> On Mon, Sep 23, 2019 at 05:37 Daniel Beck  wrote:
>>>


 On Mon, Sep 23, 2019 at 2:28 PM Sverre Moe  wrote:

> ERROR: Failed to download 
> https://services.gradle.org/distributions/gradle-5.6.2-bin.zip from 
> agent; will retry from master
>
> sun.security.provider.certpath.SunCertPathBuilderException: unable to 
> find valid certification path to requested target
>
>
>
> Which makes me believe that the Gradle tool does not use Jenkins Proxy 
> settings, while Maven tools does use it.
>

 The error means it's an SSL issue. If you're on an old JRE, update it. 

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Jenkins Users" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to jenkins...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com
  
 
 .

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/3372bae7-e425-4317-ae8c-170c8b673335%40googlegroups.com.


Re: Gradle Tool Failed Download

2019-09-25 Thread Sverre Moe
The Gradle tool installer is not the only tool having this problem. I am 
getting the same SSL problem with Groovy tool installers.

Makes me wonder, what does the maven tool installer do different than the 
Gradle and Groovy tool installers.

mandag 23. september 2019 22.26.10 UTC+2 skrev Sverre Moe følgende:
>
> I have gotten this problem both for Jenkins running Java 8u221 and Java 
> 11.0.4+11. The latest for both 8 and 11.
>
> Maven tool download works just fine, using the same JDK, so why would the 
> gradle installer have a problem?
>
> I do not like to check in the gradle wrapper files into version control, 
> but considering it might ease new developers I am beginning to lean into it.
>
> mandag 23. september 2019 18.25.04 UTC+2 skrev Jan Monterrubio følgende:
>>
>> I’ve always relied on projects supplying the gradle wrapper instead... 
>> that might be a good alternative if you can’t upgrade the JRE
>>
>> On Mon, Sep 23, 2019 at 05:37 Daniel Beck  wrote:
>>
>>>
>>>
>>> On Mon, Sep 23, 2019 at 2:28 PM Sverre Moe  wrote:
>>>
 ERROR: Failed to download 
 https://services.gradle.org/distributions/gradle-5.6.2-bin.zip from agent; 
 will retry from master

 sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
 valid certification path to requested target



 Which makes me believe that the Gradle tool does not use Jenkins Proxy 
 settings, while Maven tools does use it.

>>>
>>> The error means it's an SSL issue. If you're on an old JRE, update it. 
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jenkins...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/be305763-141f-438e-b16e-d00d4a010a30%40googlegroups.com.


Re: Gradle Tool Failed Download

2019-09-23 Thread Sverre Moe
I have gotten this problem both for Jenkins running Java 8u221 and Java 
11.0.4+11. The latest for both 8 and 11.

Maven tool download works just fine, using the same JDK, so why would the 
gradle installer have a problem?

I do not like to check in the gradle wrapper files into version control, 
but considering it might ease new developers I am beginning to lean into it.

mandag 23. september 2019 18.25.04 UTC+2 skrev Jan Monterrubio følgende:
>
> I’ve always relied on projects supplying the gradle wrapper instead... 
> that might be a good alternative if you can’t upgrade the JRE
>
> On Mon, Sep 23, 2019 at 05:37 Daniel Beck  > wrote:
>
>>
>>
>> On Mon, Sep 23, 2019 at 2:28 PM Sverre Moe > > wrote:
>>
>>> ERROR: Failed to download 
>>> https://services.gradle.org/distributions/gradle-5.6.2-bin.zip from agent; 
>>> will retry from master
>>>
>>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
>>> valid certification path to requested target
>>>
>>>
>>>
>>> Which makes me believe that the Gradle tool does not use Jenkins Proxy 
>>> settings, while Maven tools does use it.
>>>
>>
>> The error means it's an SSL issue. If you're on an old JRE, update it. 
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkins...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/318b27a4-f693-4e28-8352-c9da7b986583%40googlegroups.com.


Re: Gradle Tool Failed Download

2019-09-23 Thread Jan Monterrubio
I’ve always relied on projects supplying the gradle wrapper instead... that
might be a good alternative if you can’t upgrade the JRE

On Mon, Sep 23, 2019 at 05:37 Daniel Beck  wrote:

>
>
> On Mon, Sep 23, 2019 at 2:28 PM Sverre Moe  wrote:
>
>> ERROR: Failed to download 
>> https://services.gradle.org/distributions/gradle-5.6.2-bin.zip from agent; 
>> will retry from master
>>
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
>> valid certification path to requested target
>>
>>
>>
>> Which makes me believe that the Gradle tool does not use Jenkins Proxy
>> settings, while Maven tools does use it.
>>
>
> The error means it's an SSL issue. If you're on an old JRE, update it.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CADgiF9LYWdDQ3a-EMkxL0wXcMZn_xdBT9oBgzqiS75xxjG_z7w%40mail.gmail.com.


Re: Gradle Tool Failed Download

2019-09-23 Thread Daniel Beck
On Mon, Sep 23, 2019 at 2:28 PM Sverre Moe  wrote:

> ERROR: Failed to download 
> https://services.gradle.org/distributions/gradle-5.6.2-bin.zip from agent; 
> will retry from master
>
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>
>
>
> Which makes me believe that the Gradle tool does not use Jenkins Proxy
> settings, while Maven tools does use it.
>

The error means it's an SSL issue. If you're on an old JRE, update it.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com.


Re: Gradle Tool Failed Download

2019-09-23 Thread Sverre Moe
Jenklns has no problem downloading Maven tools, but fails downloading 
Gradle tools.

Unpacking 
https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.zip
 to /home/build/jenkins/tools/hudson.tasks.Maven_MavenInstallation/maven-3.6.1 
on sles12.3-x86_64_1


Unpacking https://services.gradle.org/distributions/gradle-5.6.2-bin.zip to

/home/build/jenkins/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.6.2 
on sles12.3-x86_64_1

ERROR: Failed to download 
https://services.gradle.org/distributions/gradle-5.6.2-bin.zip from agent; will 
retry from master

sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target



Which makes me believe that the Gradle tool does not use Jenkins Proxy 
settings, while Maven tools does use it.


fredag 9. august 2019 14.32.53 UTC+2 skrev Sverre Moe følgende:
>
> I get the same problem trying to get the gradle wrapper on our build 
> agents.
>
> Using Proxy with gradle fixes that problem:
> gradle wrapper --gradle-version=5.5.1
> ./gradlew -Dhttps.proxyHost=proxy.company.com -Dhttps.proxyPort=3128 --
> version
>
> Is there a way to get Jenkins to use this proxy when downloading the 
> Gradle distribution?
> I have configured Jenkins to use our Proxy under the Plugin Manager > 
> Advanced.
>
> However considering we want to create our own Gradle distribution now that 
> has become an option after 5.5, I think we would to stick with the option 
> of unpacking the installer our self using "Run Shell Command".
>
> onsdag 7. august 2019 23.42.57 UTC+2 skrev Sverre Moe følgende:
>>
>> I am not very keen on checking in the gradle wrapper to git. Though I do 
>> see the appeal.
>>
>> Now with Gradle 5.5 I am planning on creating a custom Gradle 
>> distribution and storing it with Nexus NXRM.
>>
>> https://docs.gradle.org/5.5/userguide/organizing_gradle_projects.html#sec:custom_gradle_distribution
>>
>> onsdag 7. august 2019 22.00.53 UTC+2 skrev Richard Bywater følgende:
>>>
>>> Personally with Gradle I've always found it easier to use Gradle Wrapper 
>>> instead of full installs.
>>>
>>> Don't know if that's an option for you or not. 
>>>
>>> Richard.
>>>
>>> On Thu, 8 Aug 2019, 7:38 AM Sverre Moe,  wrote:
>>>
 Got it working using the "Run Shell Command". Though I find it very 
 cumbersome.

 wget --quiet https://
 nexus.company.no:8443/repository/gradle-distributions/gradle-5.5.1-bin.zip
 unzip -qq gradle-5.5.1-bin.zip
 mv gradle-5.5.1/* .
 rmdir gradle-5.5.1
 rm gradle-5.5.1-bin.zip


 onsdag 7. august 2019 21.10.59 UTC+2 skrev Sverre Moe følgende:
>
> Perhaps I could use instead the Installers "Run Shell Command", or 
> "Run Batch Command".
> Then unpack it myself, ensuring it gets unpacked within the tool name 
> directory.
> Would I need both in order for it to work on Linux and Windows?
>
> onsdag 7. august 2019 21.04.09 UTC+2 skrev Sverre Moe følgende:
>>
>> I thought of the same.
>> I downloaded the Gradle distribution zip file. Placed it in our Nexus 
>> Repository Manager, in a raw repository.
>>
>> Used the Installer "Extract *.zip/*.tar.gz". Did not go so well
>> Tool: gradle-5.5
>> File: gradle-5.5.1-bin.zip
>>
>> Get extracted in
>> hudson.plugins.gradle.GradleInstallation/gradle-5.5/gradle-5.5.1
>>
>> My pipeline script suspects to find the gradle executable under 
>> ${gradleTool}/bin/gradle.
>>
>> The GradleInstaller unpacks it under the tool name.
>>
>> onsdag 7. august 2019 20.51.09 UTC+2 skrev Mark Waite følgende:
>>>
>>> Maybe this is the time to reconfigure the tool installer to download 
>>> from a locally cached copy of the tool instead of pulling it from the 
>>> internet?
>>>
>>> I've had good results with that technique by placing zip files of 
>>> the tool installers inside my network and then configuring the tool 
>>> installer to use the copy from my network instead of the copy from the 
>>> internet.
>>>
>>> On Wed, Aug 7, 2019 at 11:56 AM Sverre Moe  
>>> wrote:
>>>
 I have no modifed cacerts.

 Using wget also fails on the agent, until I set a proxy.
 The Jenkins server does have proxy configured, but not the agents.
 When I add HTTP Proxy in Jenkins under the Update Center I get a 
 totally different stacktrace when it tries to retrieve the gradle tool.

 Unpacking 
 https://services.gradle.org/distributions/gradle-5.5.1-bin.zip to 
 /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
  on master-sles12.3-x86_64_2

 ERROR: Failed to download 
 https://services.gradle.org/distributions/gradle-5.5.1-bin.zip from 
 agent; will retry from master
 

Re: Gradle Tool Failed Download

2019-08-09 Thread Sverre Moe
I get the same problem trying to get the gradle wrapper on our build agents.

Using Proxy with gradle fixes that problem:
gradle wrapper --gradle-version=5.5.1
./gradlew -Dhttps.proxyHost=proxy.company.com -Dhttps.proxyPort=3128 --
version

Is there a way to get Jenkins to use this proxy when downloading the Gradle 
distribution?
I have configured Jenkins to use our Proxy under the Plugin Manager > 
Advanced.

However considering we want to create our own Gradle distribution now that 
has become an option after 5.5, I think we would to stick with the option 
of unpacking the installer our self using "Run Shell Command".

onsdag 7. august 2019 23.42.57 UTC+2 skrev Sverre Moe følgende:
>
> I am not very keen on checking in the gradle wrapper to git. Though I do 
> see the appeal.
>
> Now with Gradle 5.5 I am planning on creating a custom Gradle distribution 
> and storing it with Nexus NXRM.
>
> https://docs.gradle.org/5.5/userguide/organizing_gradle_projects.html#sec:custom_gradle_distribution
>
> onsdag 7. august 2019 22.00.53 UTC+2 skrev Richard Bywater følgende:
>>
>> Personally with Gradle I've always found it easier to use Gradle Wrapper 
>> instead of full installs.
>>
>> Don't know if that's an option for you or not. 
>>
>> Richard.
>>
>> On Thu, 8 Aug 2019, 7:38 AM Sverre Moe,  wrote:
>>
>>> Got it working using the "Run Shell Command". Though I find it very 
>>> cumbersome.
>>>
>>> wget --quiet https://
>>> nexus.company.no:8443/repository/gradle-distributions/gradle-5.5.1-bin.zip
>>> unzip -qq gradle-5.5.1-bin.zip
>>> mv gradle-5.5.1/* .
>>> rmdir gradle-5.5.1
>>> rm gradle-5.5.1-bin.zip
>>>
>>>
>>> onsdag 7. august 2019 21.10.59 UTC+2 skrev Sverre Moe følgende:

 Perhaps I could use instead the Installers "Run Shell Command", or "Run 
 Batch Command".
 Then unpack it myself, ensuring it gets unpacked within the tool name 
 directory.
 Would I need both in order for it to work on Linux and Windows?

 onsdag 7. august 2019 21.04.09 UTC+2 skrev Sverre Moe følgende:
>
> I thought of the same.
> I downloaded the Gradle distribution zip file. Placed it in our Nexus 
> Repository Manager, in a raw repository.
>
> Used the Installer "Extract *.zip/*.tar.gz". Did not go so well
> Tool: gradle-5.5
> File: gradle-5.5.1-bin.zip
>
> Get extracted in
> hudson.plugins.gradle.GradleInstallation/gradle-5.5/gradle-5.5.1
>
> My pipeline script suspects to find the gradle executable under 
> ${gradleTool}/bin/gradle.
>
> The GradleInstaller unpacks it under the tool name.
>
> onsdag 7. august 2019 20.51.09 UTC+2 skrev Mark Waite følgende:
>>
>> Maybe this is the time to reconfigure the tool installer to download 
>> from a locally cached copy of the tool instead of pulling it from the 
>> internet?
>>
>> I've had good results with that technique by placing zip files of the 
>> tool installers inside my network and then configuring the tool 
>> installer 
>> to use the copy from my network instead of the copy from the internet.
>>
>> On Wed, Aug 7, 2019 at 11:56 AM Sverre Moe  wrote:
>>
>>> I have no modifed cacerts.
>>>
>>> Using wget also fails on the agent, until I set a proxy.
>>> The Jenkins server does have proxy configured, but not the agents.
>>> When I add HTTP Proxy in Jenkins under the Update Center I get a 
>>> totally different stacktrace when it tries to retrieve the gradle tool.
>>>
>>> Unpacking 
>>> https://services.gradle.org/distributions/gradle-5.5.1-bin.zip to 
>>> /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
>>>  on master-sles12.3-x86_64_2
>>>
>>> ERROR: Failed to download 
>>> https://services.gradle.org/distributions/gradle-5.5.1-bin.zip from 
>>> agent; will retry from master
>>> sun.security.provider.certpath.SunCertPathBuilderException: unable to 
>>> find valid certification path to requested target
>>> at 
>>> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>>> at 
>>> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>>> at 
>>> java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
>>> at 
>>> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
>>> Caused: sun.security.validator.ValidatorException: PKIX path building 
>>> failed
>>> at 
>>> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
>>> at 
>>> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
>>> at sun.security.validator.Validator.validate(Validator.java:262)
>>> at 
>>> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
>>> at 
>>> 

Re: Gradle Tool Failed Download

2019-08-07 Thread Sverre Moe
I am not very keen on checking in the gradle wrapper to git. Though I do 
see the appeal.

Now with Gradle 5.5 I am planning on creating a custom Gradle distribution 
and storing it with Nexus NXRM.
https://docs.gradle.org/5.5/userguide/organizing_gradle_projects.html#sec:custom_gradle_distribution

onsdag 7. august 2019 22.00.53 UTC+2 skrev Richard Bywater følgende:
>
> Personally with Gradle I've always found it easier to use Gradle Wrapper 
> instead of full installs.
>
> Don't know if that's an option for you or not. 
>
> Richard.
>
> On Thu, 8 Aug 2019, 7:38 AM Sverre Moe, > 
> wrote:
>
>> Got it working using the "Run Shell Command". Though I find it very 
>> cumbersome.
>>
>> wget --quiet https://
>> nexus.company.no:8443/repository/gradle-distributions/gradle-5.5.1-bin.zip
>> unzip -qq gradle-5.5.1-bin.zip
>> mv gradle-5.5.1/* .
>> rmdir gradle-5.5.1
>> rm gradle-5.5.1-bin.zip
>>
>>
>> onsdag 7. august 2019 21.10.59 UTC+2 skrev Sverre Moe følgende:
>>>
>>> Perhaps I could use instead the Installers "Run Shell Command", or "Run 
>>> Batch Command".
>>> Then unpack it myself, ensuring it gets unpacked within the tool name 
>>> directory.
>>> Would I need both in order for it to work on Linux and Windows?
>>>
>>> onsdag 7. august 2019 21.04.09 UTC+2 skrev Sverre Moe følgende:

 I thought of the same.
 I downloaded the Gradle distribution zip file. Placed it in our Nexus 
 Repository Manager, in a raw repository.

 Used the Installer "Extract *.zip/*.tar.gz". Did not go so well
 Tool: gradle-5.5
 File: gradle-5.5.1-bin.zip

 Get extracted in
 hudson.plugins.gradle.GradleInstallation/gradle-5.5/gradle-5.5.1

 My pipeline script suspects to find the gradle executable under 
 ${gradleTool}/bin/gradle.

 The GradleInstaller unpacks it under the tool name.

 onsdag 7. august 2019 20.51.09 UTC+2 skrev Mark Waite følgende:
>
> Maybe this is the time to reconfigure the tool installer to download 
> from a locally cached copy of the tool instead of pulling it from the 
> internet?
>
> I've had good results with that technique by placing zip files of the 
> tool installers inside my network and then configuring the tool installer 
> to use the copy from my network instead of the copy from the internet.
>
> On Wed, Aug 7, 2019 at 11:56 AM Sverre Moe  wrote:
>
>> I have no modifed cacerts.
>>
>> Using wget also fails on the agent, until I set a proxy.
>> The Jenkins server does have proxy configured, but not the agents.
>> When I add HTTP Proxy in Jenkins under the Update Center I get a 
>> totally different stacktrace when it tries to retrieve the gradle tool.
>>
>> Unpacking https://services.gradle.org/distributions/gradle-5.5.1-bin.zip 
>> to 
>> /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
>>  on master-sles12.3-x86_64_2
>>
>> ERROR: Failed to download 
>> https://services.gradle.org/distributions/gradle-5.5.1-bin.zip from 
>> agent; will retry from master
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to 
>> find valid certification path to requested target
>>  at 
>> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>>  at 
>> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>>  at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
>>  at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
>> Caused: sun.security.validator.ValidatorException: PKIX path building 
>> failed
>>  at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
>>  at 
>> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
>>  at sun.security.validator.Validator.validate(Validator.java:262)
>>  at 
>> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
>>  at 
>> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:237)
>>  at 
>> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
>>  at 
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
>> Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
>> master-sles12.3-x86_64_2
>>  at 
>> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
>>  at 
>> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
>>  at hudson.remoting.Channel.call(Channel.java:957)
>>  at hudson.FilePath.act(FilePath.java:1070)
>>  at hudson.FilePath.act(FilePath.java:1059)
>>  at hudson.FilePath.installIfNecessaryFrom(FilePath.java:913)
>>  at 

Re: Gradle Tool Failed Download

2019-08-07 Thread Richard Bywater
Personally with Gradle I've always found it easier to use Gradle Wrapper
instead of full installs.

Don't know if that's an option for you or not.

Richard.

On Thu, 8 Aug 2019, 7:38 AM Sverre Moe,  wrote:

> Got it working using the "Run Shell Command". Though I find it very
> cumbersome.
>
> wget --quiet https://
> nexus.company.no:8443/repository/gradle-distributions/gradle-5.5.1-bin.zip
> unzip -qq gradle-5.5.1-bin.zip
> mv gradle-5.5.1/* .
> rmdir gradle-5.5.1
> rm gradle-5.5.1-bin.zip
>
>
> onsdag 7. august 2019 21.10.59 UTC+2 skrev Sverre Moe følgende:
>>
>> Perhaps I could use instead the Installers "Run Shell Command", or "Run
>> Batch Command".
>> Then unpack it myself, ensuring it gets unpacked within the tool name
>> directory.
>> Would I need both in order for it to work on Linux and Windows?
>>
>> onsdag 7. august 2019 21.04.09 UTC+2 skrev Sverre Moe følgende:
>>>
>>> I thought of the same.
>>> I downloaded the Gradle distribution zip file. Placed it in our Nexus
>>> Repository Manager, in a raw repository.
>>>
>>> Used the Installer "Extract *.zip/*.tar.gz". Did not go so well
>>> Tool: gradle-5.5
>>> File: gradle-5.5.1-bin.zip
>>>
>>> Get extracted in
>>> hudson.plugins.gradle.GradleInstallation/gradle-5.5/gradle-5.5.1
>>>
>>> My pipeline script suspects to find the gradle executable under
>>> ${gradleTool}/bin/gradle.
>>>
>>> The GradleInstaller unpacks it under the tool name.
>>>
>>> onsdag 7. august 2019 20.51.09 UTC+2 skrev Mark Waite følgende:

 Maybe this is the time to reconfigure the tool installer to download
 from a locally cached copy of the tool instead of pulling it from the
 internet?

 I've had good results with that technique by placing zip files of the
 tool installers inside my network and then configuring the tool installer
 to use the copy from my network instead of the copy from the internet.

 On Wed, Aug 7, 2019 at 11:56 AM Sverre Moe  wrote:

> I have no modifed cacerts.
>
> Using wget also fails on the agent, until I set a proxy.
> The Jenkins server does have proxy configured, but not the agents.
> When I add HTTP Proxy in Jenkins under the Update Center I get a
> totally different stacktrace when it tries to retrieve the gradle tool.
>
> Unpacking https://services.gradle.org/distributions/gradle-5.5.1-bin.zip 
> to 
> /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
>  on master-sles12.3-x86_64_2
>
> ERROR: Failed to download 
> https://services.gradle.org/distributions/gradle-5.5.1-bin.zip from 
> agent; will retry from master
> sun.security.provider.certpath.SunCertPathBuilderException: unable to 
> find valid certification path to requested target
>   at 
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>   at 
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>   at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
>   at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
> Caused: sun.security.validator.ValidatorException: PKIX path building 
> failed
>   at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
>   at 
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
>   at sun.security.validator.Validator.validate(Validator.java:262)
>   at 
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
>   at 
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:237)
>   at 
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
>   at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
> Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
> master-sles12.3-x86_64_2
>   at 
> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
>   at 
> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
>   at hudson.remoting.Channel.call(Channel.java:957)
>   at hudson.FilePath.act(FilePath.java:1070)
>   at hudson.FilePath.act(FilePath.java:1059)
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:913)
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:846)
>   at 
> hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:77)
>   at 
> hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:69)
>   at 
> hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109)
>   at 
> hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206)
>   at 
> 

Re: Gradle Tool Failed Download

2019-08-07 Thread Sverre Moe
Got it working using the "Run Shell Command". Though I find it very 
cumbersome.

wget --quiet https:
//nexus.company.no:8443/repository/gradle-distributions/gradle-5.5.1-bin.zip
unzip -qq gradle-5.5.1-bin.zip
mv gradle-5.5.1/* .
rmdir gradle-5.5.1
rm gradle-5.5.1-bin.zip


onsdag 7. august 2019 21.10.59 UTC+2 skrev Sverre Moe følgende:
>
> Perhaps I could use instead the Installers "Run Shell Command", or "Run 
> Batch Command".
> Then unpack it myself, ensuring it gets unpacked within the tool name 
> directory.
> Would I need both in order for it to work on Linux and Windows?
>
> onsdag 7. august 2019 21.04.09 UTC+2 skrev Sverre Moe følgende:
>>
>> I thought of the same.
>> I downloaded the Gradle distribution zip file. Placed it in our Nexus 
>> Repository Manager, in a raw repository.
>>
>> Used the Installer "Extract *.zip/*.tar.gz". Did not go so well
>> Tool: gradle-5.5
>> File: gradle-5.5.1-bin.zip
>>
>> Get extracted in
>> hudson.plugins.gradle.GradleInstallation/gradle-5.5/gradle-5.5.1
>>
>> My pipeline script suspects to find the gradle executable under 
>> ${gradleTool}/bin/gradle.
>>
>> The GradleInstaller unpacks it under the tool name.
>>
>> onsdag 7. august 2019 20.51.09 UTC+2 skrev Mark Waite følgende:
>>>
>>> Maybe this is the time to reconfigure the tool installer to download 
>>> from a locally cached copy of the tool instead of pulling it from the 
>>> internet?
>>>
>>> I've had good results with that technique by placing zip files of the 
>>> tool installers inside my network and then configuring the tool installer 
>>> to use the copy from my network instead of the copy from the internet.
>>>
>>> On Wed, Aug 7, 2019 at 11:56 AM Sverre Moe  wrote:
>>>
 I have no modifed cacerts.

 Using wget also fails on the agent, until I set a proxy.
 The Jenkins server does have proxy configured, but not the agents.
 When I add HTTP Proxy in Jenkins under the Update Center I get a 
 totally different stacktrace when it tries to retrieve the gradle tool.

 Unpacking https://services.gradle.org/distributions/gradle-5.5.1-bin.zip 
 to 
 /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
  on master-sles12.3-x86_64_2

 ERROR: Failed to download 
 https://services.gradle.org/distributions/gradle-5.5.1-bin.zip from agent; 
 will retry from master
 sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
 valid certification path to requested target
at 
 sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at 
 sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
 Caused: sun.security.validator.ValidatorException: PKIX path building 
 failed
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
at 
 sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
at sun.security.validator.Validator.validate(Validator.java:262)
at 
 sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
at 
 sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:237)
at 
 sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
at 
 sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
 Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
 master-sles12.3-x86_64_2
at 
 hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
 hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at hudson.FilePath.act(FilePath.java:1070)
at hudson.FilePath.act(FilePath.java:1059)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:913)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:846)
at 
 hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:77)
at 
 hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:69)
at 
 hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109)
at 
 hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206)
at 
 hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:92)
at 
 hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:30)
at 
 org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:152)
at 

Re: Gradle Tool Failed Download

2019-08-07 Thread Sverre Moe
Perhaps I could use instead the Installers "Run Shell Command", or "Run 
Batch Command".
Then unpack it myself, ensuring it gets unpacked within the tool name 
directory.
Would I need both in order for it to work on Linux and Windows?

onsdag 7. august 2019 21.04.09 UTC+2 skrev Sverre Moe følgende:
>
> I thought of the same.
> I downloaded the Gradle distribution zip file. Placed it in our Nexus 
> Repository Manager, in a raw repository.
>
> Used the Installer "Extract *.zip/*.tar.gz". Did not go so well
> Tool: gradle-5.5
> File: gradle-5.5.1-bin.zip
>
> Get extracted in
> hudson.plugins.gradle.GradleInstallation/gradle-5.5/gradle-5.5.1
>
> My pipeline script suspects to find the gradle executable under 
> ${gradleTool}/bin/gradle.
>
> The GradleInstaller unpacks it under the tool name.
>
> onsdag 7. august 2019 20.51.09 UTC+2 skrev Mark Waite følgende:
>>
>> Maybe this is the time to reconfigure the tool installer to download from 
>> a locally cached copy of the tool instead of pulling it from the internet?
>>
>> I've had good results with that technique by placing zip files of the 
>> tool installers inside my network and then configuring the tool installer 
>> to use the copy from my network instead of the copy from the internet.
>>
>> On Wed, Aug 7, 2019 at 11:56 AM Sverre Moe  wrote:
>>
>>> I have no modifed cacerts.
>>>
>>> Using wget also fails on the agent, until I set a proxy.
>>> The Jenkins server does have proxy configured, but not the agents.
>>> When I add HTTP Proxy in Jenkins under the Update Center I get a totally 
>>> different stacktrace when it tries to retrieve the gradle tool.
>>>
>>> Unpacking https://services.gradle.org/distributions/gradle-5.5.1-bin.zip to 
>>> /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
>>>  on master-sles12.3-x86_64_2
>>>
>>> ERROR: Failed to download 
>>> https://services.gradle.org/distributions/gradle-5.5.1-bin.zip from agent; 
>>> will retry from master
>>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
>>> valid certification path to requested target
>>> at 
>>> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>>> at 
>>> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>>> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
>>> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
>>> Caused: sun.security.validator.ValidatorException: PKIX path building failed
>>> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
>>> at 
>>> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
>>> at sun.security.validator.Validator.validate(Validator.java:262)
>>> at 
>>> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
>>> at 
>>> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:237)
>>> at 
>>> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
>>> at 
>>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
>>> Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
>>> master-sles12.3-x86_64_2
>>> at 
>>> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
>>> at 
>>> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
>>> at hudson.remoting.Channel.call(Channel.java:957)
>>> at hudson.FilePath.act(FilePath.java:1070)
>>> at hudson.FilePath.act(FilePath.java:1059)
>>> at hudson.FilePath.installIfNecessaryFrom(FilePath.java:913)
>>> at hudson.FilePath.installIfNecessaryFrom(FilePath.java:846)
>>> at 
>>> hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:77)
>>> at 
>>> hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:69)
>>> at 
>>> hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109)
>>> at 
>>> hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206)
>>> at 
>>> hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:92)
>>> at 
>>> hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:30)
>>> at 
>>> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:152)
>>> at 
>>> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:133)
>>> at 
>>> org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
>>> at 
>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>>> at 
>>> 

Re: Gradle Tool Failed Download

2019-08-07 Thread Sverre Moe
I thought of the same.
I downloaded the Gradle distribution zip file. Placed it in our Nexus 
Repository Manager, in a raw repository.

Used the Installer "Extract *.zip/*.tar.gz". Did not go so well
Tool: gradle-5.5
File: gradle-5.5.1-bin.zip

Get extracted in
hudson.plugins.gradle.GradleInstallation/gradle-5.5/gradle-5.5.1

My pipeline script suspects to find the gradle executable under 
${gradleTool}/bin/gradle.

The GradleInstaller unpacks it under the tool name.

onsdag 7. august 2019 20.51.09 UTC+2 skrev Mark Waite følgende:
>
> Maybe this is the time to reconfigure the tool installer to download from 
> a locally cached copy of the tool instead of pulling it from the internet?
>
> I've had good results with that technique by placing zip files of the tool 
> installers inside my network and then configuring the tool installer to use 
> the copy from my network instead of the copy from the internet.
>
> On Wed, Aug 7, 2019 at 11:56 AM Sverre Moe  > wrote:
>
>> I have no modifed cacerts.
>>
>> Using wget also fails on the agent, until I set a proxy.
>> The Jenkins server does have proxy configured, but not the agents.
>> When I add HTTP Proxy in Jenkins under the Update Center I get a totally 
>> different stacktrace when it tries to retrieve the gradle tool.
>>
>> Unpacking https://services.gradle.org/distributions/gradle-5.5.1-bin.zip to 
>> /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
>>  on master-sles12.3-x86_64_2
>>
>> ERROR: Failed to download 
>> https://services.gradle.org/distributions/gradle-5.5.1-bin.zip from agent; 
>> will retry from master
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
>> valid certification path to requested target
>>  at 
>> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>>  at 
>> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>>  at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
>>  at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
>> Caused: sun.security.validator.ValidatorException: PKIX path building failed
>>  at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
>>  at 
>> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
>>  at sun.security.validator.Validator.validate(Validator.java:262)
>>  at 
>> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
>>  at 
>> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:237)
>>  at 
>> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
>>  at 
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
>> Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
>> master-sles12.3-x86_64_2
>>  at 
>> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
>>  at 
>> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
>>  at hudson.remoting.Channel.call(Channel.java:957)
>>  at hudson.FilePath.act(FilePath.java:1070)
>>  at hudson.FilePath.act(FilePath.java:1059)
>>  at hudson.FilePath.installIfNecessaryFrom(FilePath.java:913)
>>  at hudson.FilePath.installIfNecessaryFrom(FilePath.java:846)
>>  at 
>> hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:77)
>>  at 
>> hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:69)
>>  at 
>> hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109)
>>  at 
>> hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206)
>>  at 
>> hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:92)
>>  at 
>> hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:30)
>>  at 
>> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:152)
>>  at 
>> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:133)
>>  at 
>> org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
>>  at 
>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>>  at 
>> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>>  at 
>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>>  at 
>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>>  at java.base/java.lang.Thread.run(Thread.java:834)
>> Caused: javax.net.ssl.SSLHandshakeException
>>  at 

Re: Gradle Tool Failed Download

2019-08-07 Thread Mark Waite
Maybe this is the time to reconfigure the tool installer to download from a
locally cached copy of the tool instead of pulling it from the internet?

I've had good results with that technique by placing zip files of the tool
installers inside my network and then configuring the tool installer to use
the copy from my network instead of the copy from the internet.

On Wed, Aug 7, 2019 at 11:56 AM Sverre Moe  wrote:

> I have no modifed cacerts.
>
> Using wget also fails on the agent, until I set a proxy.
> The Jenkins server does have proxy configured, but not the agents.
> When I add HTTP Proxy in Jenkins under the Update Center I get a totally
> different stacktrace when it tries to retrieve the gradle tool.
>
> Unpacking https://services.gradle.org/distributions/gradle-5.5.1-bin.zip to 
> /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
>  on master-sles12.3-x86_64_2
>
> ERROR: Failed to download 
> https://services.gradle.org/distributions/gradle-5.5.1-bin.zip from agent; 
> will retry from master
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>   at 
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>   at 
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>   at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
>   at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
> Caused: sun.security.validator.ValidatorException: PKIX path building failed
>   at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
>   at 
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
>   at sun.security.validator.Validator.validate(Validator.java:262)
>   at 
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
>   at 
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:237)
>   at 
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
>   at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
> Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
> master-sles12.3-x86_64_2
>   at 
> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
>   at 
> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
>   at hudson.remoting.Channel.call(Channel.java:957)
>   at hudson.FilePath.act(FilePath.java:1070)
>   at hudson.FilePath.act(FilePath.java:1059)
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:913)
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:846)
>   at 
> hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:77)
>   at 
> hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:69)
>   at 
> hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109)
>   at 
> hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206)
>   at 
> hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:92)
>   at 
> hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:30)
>   at 
> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:152)
>   at 
> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:133)
>   at 
> org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>   at 
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> Caused: javax.net.ssl.SSLHandshakeException
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>   at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
>   at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
>   at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
>   at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
>   at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
>   at 

Re: Gradle Tool Failed Download

2019-08-07 Thread Sverre Moe
I have no modifed cacerts.

Using wget also fails on the agent, until I set a proxy.
The Jenkins server does have proxy configured, but not the agents.
When I add HTTP Proxy in Jenkins under the Update Center I get a totally 
different stacktrace when it tries to retrieve the gradle tool.

Unpacking https://services.gradle.org/distributions/gradle-5.5.1-bin.zip to 
/home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
 on master-sles12.3-x86_64_2

ERROR: Failed to download 
https://services.gradle.org/distributions/gradle-5.5.1-bin.zip from agent; will 
retry from master
sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target
at 
sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at 
sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
Caused: sun.security.validator.ValidatorException: PKIX path building failed
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
at 
sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
at sun.security.validator.Validator.validate(Validator.java:262)
at 
sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
at 
sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:237)
at 
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
at 
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
master-sles12.3-x86_64_2
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at hudson.FilePath.act(FilePath.java:1070)
at hudson.FilePath.act(FilePath.java:1059)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:913)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:846)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:77)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:69)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109)
at 
hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206)
at 
hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:92)
at 
hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:30)
at 
org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:152)
at 
org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:133)
at 
org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at 
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused: javax.net.ssl.SSLHandshakeException
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
at 
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
at 
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
at 
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at 

Re: Gradle Tool Failed Download

2019-08-07 Thread Mark Waite
I would guess that you may already be using a modified cacerts file which
does not include the authority that is certifying the validity of the SSL
certificate on the gradle site.

When I download from that URL, my web browser reports no issues from Google
Chrome on Windows and no issues from wget on a FreeBSD computer.

On Wed, Aug 7, 2019 at 10:51 AM Sverre Moe  wrote:

> This has worked before. Now that we where to upgrade from Gradle 5.0 to
> 5.5 and added the tool gradle-5.5 it fails to retrieve the archive.
>
> Anyone have an idea what the problem might be?
>
> Running both Jenkins and Agents on Java 8 Update 221.
>
> Is there any way arround this without hacking the JRE cacerts with the
> gradle web site certificate?
>
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>   at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>   at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>   at 
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
>   at 
> java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
> Caused: sun.security.validator.ValidatorException: PKIX path building failed
>   at 
> java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385)
>   at 
> java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:290)
>   at 
> java.base/sun.security.validator.Validator.validate(Validator.java:264)
>   at 
> java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:321)
>   at 
> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:221)
>   at 
> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
>   at 
> java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:626)
> Caused: javax.net.ssl.SSLHandshakeException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>   at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>   at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
>   at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
>   at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
>   at 
> java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:642)
>   at 
> java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:461)
>   at 
> java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:361)
>   at 
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>   at 
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:448)
>   at 
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:425)
>   at 
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
>   at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>   at 
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>   at 
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>   at 
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>   at 
> java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
>   at 
> java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection.followRedirect0(HttpURLConnection.java:2768)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection.followRedirect(HttpURLConnection.java:2680)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1843)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
>   at 
> java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:527)
>   at 
> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:329)
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:874)
> Caused: java.io.IOException: Failed to install 
> https://services.gradle.org/distributions/gradle-5.5.1-bin.zip to 
> /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:938)
>   at 

Re: Gradle Tool Failed Download

2019-08-07 Thread Sverre Moe
I don't think this is a problem with the Tool as I get the same problem 
trying manually on the agent

build@jbssles123x64:~/workspace/meos-dashboard> gradle wrapper 
--gradle-version=5.5.1 
build@jbssles123x64:~/workspace/project> ./gradlew --version 
Downloading https://services.gradle.org/distributions/gradle-5.5.1-bin.zip

Gives same Stacktrace.

onsdag 7. august 2019 18.51.37 UTC+2 skrev Sverre Moe følgende:
>
> This has worked before. Now that we where to upgrade from Gradle 5.0 to 
> 5.5 and added the tool gradle-5.5 it fails to retrieve the archive.
>
> Anyone have an idea what the problem might be?
>
> Running both Jenkins and Agents on Java 8 Update 221.
>
> Is there any way arround this without hacking the JRE cacerts with the 
> gradle web site certificate?
>
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>   at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>   at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>   at 
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
>   at 
> java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
> Caused: sun.security.validator.ValidatorException: PKIX path building failed
>   at 
> java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385)
>   at 
> java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:290)
>   at 
> java.base/sun.security.validator.Validator.validate(Validator.java:264)
>   at 
> java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:321)
>   at 
> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:221)
>   at 
> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
>   at 
> java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:626)
> Caused: javax.net.ssl.SSLHandshakeException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>   at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>   at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
>   at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
>   at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
>   at 
> java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:642)
>   at 
> java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:461)
>   at 
> java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:361)
>   at 
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>   at 
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:448)
>   at 
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:425)
>   at 
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
>   at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>   at 
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>   at 
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>   at 
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>   at 
> java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
>   at 
> java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection.followRedirect0(HttpURLConnection.java:2768)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection.followRedirect(HttpURLConnection.java:2680)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1843)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
>   at 
> java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:527)
>   at 
> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:329)
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:874)
> Caused: java.io.IOException: Failed to install 
> https://services.gradle.org/distributions/gradle-5.5.1-bin.zip to 
> /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
>   at