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 g
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
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 qualit
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
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 t
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 M
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,
b
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.gradl
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 reque
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
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 downl
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
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
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
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.GradleInstallat
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 us
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.
Unpackin
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
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/distri
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
21 matches
Mail list logo
