Re: Use AdoptOpenJDK as JDK Tool download source

[Sverre Moe]

In that case, you suggested a solution with a repository manager like 
Sonatype Nexus or Artifactory.
I like this proposal and we already are using Nexus in our organization.

Our Linux build servers have OpenJDK available to be installed through SUSE 
repositories.
It is mostly for our Windows and Mac builds we need either an older Oracle 
JDK or the newer OpenJDK. Up to now the JDK has been updated manually on 
these build servers.

mandag 4. mars 2019 15.26.13 UTC+1 skrev Baptiste Mathus følgende:
>
> It's not even about removing the JDK automated installer.
> It is about removing the feature that will automatically propose you to 
> download a JDK from external providers, like from oracle.com in the past, 
> or from adoptopenjdk.net as it is being proposed. Because this is bad 
> idea to constantly download the JDK from outside your company network for 
> many reasons I already listed in 
> https://issues.jenkins-ci.org/browse/JENKINS-54305?focusedCommentId=360351&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-360351
>  
> 
>
> Le mar. 26 févr. 2019 à 21:47, Mykola Nikishov  > a écrit :
>
>> nicolas de loof >
>> writes:
>>
>> > but docker images seems to me a way better solution to cover the same
>> > need, and this "tool installer" feature is just a hack-ish legacy we
>> > should deprecate.
>>
>> Are you proposing to remove tool installer completely or is it about JDK
>> tool installer only?
>>
>> If the former, to me this looks like maven vs freestyle project type
>> issue (when you have Maven project, of course) but moving in opposite
>> direction, from generic to concrete one. Tool installer is a generic
>> installer that supports installation of different tools. Docker images
>> support only a subset of these use-cases.
>>
>> > Le mar. 26 févr. 2019 à 15:44, Slide
>> >> a écrit :
>> >
>> >> How many people use the automatic installation, is there a way to track
>> >> that? Would it kill someone's usage model to remove this feature? It 
>> seems
>> >> to me to be fairly unsustainable.
>> >>
>> >> On Tue, Feb 26, 2019, 06:22 Baptiste Mathus > > wrote:
>> >>
>> >>> Hey Martijn,
>> >>>
>> >>> Thanks for chiming in. I already have commented there in the JIRA, but
>> >>> asking here since it seems at this stage better suited in a discussion
>> >>> place: do you have an opinion/idea about whether, and how long, it 
>> will be
>> >>> tolerated that certain IPs download the same JDK binaries from
>> >>> adoptopenjdk.net  like dozens or 
>> hundreds
>> >>> of time a day? I mean: how is the bandwidth consumption handled on
>> >>> adoptopenjdk.net? Isn"t there a risk that some users be banned from
>> >>> downloading from there if they suck for instance +100GB, or much 
>> more, of
>> >>> bandwidth a day?
>> >>>
>> >>> I'm asking because I've been arguing there and some other places that
>> >>> anyway this feature has always been problematic. And I tend to think 
>> it's
>> >>> cool for demos, but that normal usages shouldn't rely on downloading
>> >>> binaries from an external source forever, for a variety of reasons 
>> I've
>> >>> listed in the JIRA issue linked previously.
>>
>> -- 
>> Mykola
>>
>> Libre/Free Java Software Engineer
>> https://manandbytes.gitlab.io/
>>
>> -- 
>> 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-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/87h8cqff9u.fsf%40think.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/ea36afa9-ea8d-4e8a-8d87-0b65e438d384%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins Pipelines: Use jx-release-version

[Sverre Moe]

I read the CloudBees blog on jx-release-version.
>
> x-release-version calculates the next version number based on the current 
> Git tag, or current specified version on pom.xml/Makefile

https://www.cloudbees.com/blog/automatically-versioning-your-application-jenkins-x

It looks interesting to determine next version. Is it only available for 
Jenkins X?

We use something like automatic versioning based on the number of git 
commits.
Current version v1.0.0
Add 5 commits, push and next version is v1.0.5
This is because we didn't want to make bump commits any more.
With this jx-release-version we could get the same advantage, but not get 
the next version minor as a commit count from the last.

Can this tool be used with standard Jenkins installation and our Pipeline 
scripts?

What about Gradle, automake and cmake? Is there plans to support these also?
build.gradle
version = 1.0.0-SNAPSHOT
CMakeLists.txt
project(application VERSION 1.0.0)
configure.ac
AC_INIT(application, 1.0.0)

Our projects with automake (configure.ac) and cmake (CMakeLists.txt) does 
not use the SNAPSHOT postfix on version. It is only used for Java projects 
with Maven and Gradle.

-- 
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/3a6af824-7b4b-4325-8824-37253ddbcf1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Performance loading slow

[Sverre Moe]

We have enabled cache for LDAP authentication
Cache size 20
Cache TTL 5 min 0 sec


Is there a workaround? Disabling cache perhaps?

onsdag 20. mars 2019 00.03.01 UTC+1 skrev Stuart Rowe følgende:
>
> Since you have the Active Directory plugin installed, can you confirm that 
> you have caching enabled? We were bit by this when upgrading a test 
> instance to LTS 2.150.2.
> See: https://issues.jenkins-ci.org/browse/JENKINS-56243
>

-- 
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/648c5437-b0d1-44e6-a281-9dcb86712da7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Performance loading slow

[Sverre Moe]

The LDAP caching is supposed to increase performance

> Some LDAP servers may be slow, or rate limit client requests. In such 
cases enabling caching may improve performance of Jenkins with the risk of 
delayed propagation of user changes from LDAP and increased memory usage on 
the master. 

onsdag 20. mars 2019 15.15.14 UTC+1 skrev Sverre Moe følgende:
>
> We have enabled cache for LDAP authentication
> Cache size 20
> Cache TTL 5 min 0 sec
>
>
> Is there a workaround? Disabling cache perhaps?
>
> onsdag 20. mars 2019 00.03.01 UTC+1 skrev Stuart Rowe følgende:
>>
>> Since you have the Active Directory plugin installed, can you confirm 
>> that you have caching enabled? We were bit by this when upgrading a test 
>> instance to LTS 2.150.2.
>> See: https://issues.jenkins-ci.org/browse/JENKINS-56243
>>
>

-- 
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/b12c6225-e78f-46c4-80b7-fa8233375e69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Performance loading slow

[Sverre Moe]

I tried increasing the cache
Size 50
TTL 1 hour

Still loading is really slow for some.
Refresh main page, fast. Then I try to enter a project. and I click and 
click and click, wait and wait, but nothing. Then it just loads after 
several seconds.

onsdag 20. mars 2019 15.16.03 UTC+1 skrev Sverre Moe følgende:
>
> The LDAP caching is supposed to increase performance
>
> > Some LDAP servers may be slow, or rate limit client requests. In such 
> cases enabling caching may improve performance of Jenkins with the risk of 
> delayed propagation of user changes from LDAP and increased memory usage on 
> the master. 
>
> onsdag 20. mars 2019 15.15.14 UTC+1 skrev Sverre Moe følgende:
>>
>> We have enabled cache for LDAP authentication
>> Cache size 20
>> Cache TTL 5 min 0 sec
>>
>>
>> Is there a workaround? Disabling cache perhaps?
>>
>> onsdag 20. mars 2019 00.03.01 UTC+1 skrev Stuart Rowe følgende:
>>>
>>> Since you have the Active Directory plugin installed, can you confirm 
>>> that you have caching enabled? We were bit by this when upgrading a test 
>>> instance to LTS 2.150.2.
>>> See: https://issues.jenkins-ci.org/browse/JENKINS-56243
>>>
>>

-- 
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/b2049f8b-3b83-4ab7-9ce2-62e30616f43f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Performance loading slow

[Sverre Moe]

I did try to delete the cookies from Jenkins, and it became much faster at 
loading.

onsdag 20. mars 2019 15.22.52 UTC+1 skrev Sverre Moe følgende:
>
> I tried increasing the cache
> Size 50
> TTL 1 hour
>
> Still loading is really slow for some.
> Refresh main page, fast. Then I try to enter a project. and I click and 
> click and click, wait and wait, but nothing. Then it just loads after 
> several seconds.
>
> onsdag 20. mars 2019 15.16.03 UTC+1 skrev Sverre Moe følgende:
>>
>> The LDAP caching is supposed to increase performance
>>
>> > Some LDAP servers may be slow, or rate limit client requests. In such 
>> cases enabling caching may improve performance of Jenkins with the risk of 
>> delayed propagation of user changes from LDAP and increased memory usage on 
>> the master. 
>>
>> onsdag 20. mars 2019 15.15.14 UTC+1 skrev Sverre Moe følgende:
>>>
>>> We have enabled cache for LDAP authentication
>>> Cache size 20
>>> Cache TTL 5 min 0 sec
>>>
>>>
>>> Is there a workaround? Disabling cache perhaps?
>>>
>>> onsdag 20. mars 2019 00.03.01 UTC+1 skrev Stuart Rowe følgende:
>>>>
>>>> Since you have the Active Directory plugin installed, can you confirm 
>>>> that you have caching enabled? We were bit by this when upgrading a test 
>>>> instance to LTS 2.150.2.
>>>> See: https://issues.jenkins-ci.org/browse/JENKINS-56243
>>>>
>>>

-- 
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/273a70c8-b433-4bba-8806-f79e9d48780d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins Startup warning cannot find files

[Sverre Moe]

During each startup Jenkins comes out with a lot of:
WARNING Could not find file /var/lib/jenkins/jobs/projectA/branches/*

It is Multibranch pipeline projects.
What is this about and how can I fix 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/cdc8b186-c24c-4f69-8db6-fd4270232b8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Blue Ocean: Hide certain projects from Pipelines

[Sverre Moe]

Is it possible to not show certain pipelines in Blue Ocean.

We have one coverity job for each project.
ProjectA
ProjectA_cov
ProjectB
ProjectB_cov

This pollutes the Pipelines list in Blue Ocean. Is it possible to avoid 
seing them.
In Jenkins Classic, we have views where these projects are not visible.

-- 
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/b1214386-64e0-4055-9ca4-02641879b331%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Unit tests for Scripted Pipeline

[Sverre Moe]

Is it possible to create unit tests for our scripted pipeline?

How can certain sections of the pipeline be mocked, like fetching from Git, 
tagging to Git, Uploading to Nexus?

Anyone been able to fully unit test scripted pipeline?

I found this project at GitHub regarding Unit testing pipelines.
https://github.com/jenkinsci/JenkinsPipelineUnit


-- 
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/bfb4737c-8813-40ef-be39-193d905cd1b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Startup warning cannot find files

[Sverre Moe]

There was no more output. Just two lines of Warning, lots of them

2019.04.04 10:30.00 com.cloudbees.hudson.plugins.folder.AbstractFolder 
loadChildren
WARNING: Could not find file 
/var/lib/jenkins/jobs/projectName/branches/branchName/config.xml

søndag 7. april 2019 22.08.21 UTC+2 skrev Ivan Fernandez Calvo følgende:
>
> Without the whole exception it is difficult to help you on something, 
> however this error could be related to previous errors, you have to check 
> the first exceptions in logs would be the real cause to cannot read files, 
> also check the warnings and errors in manage Jenkins page, I bet you have 
> plugins that failed to load for some break dependency, if so update your 
> plugins is the solution.

-- 
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/d6db8aea-9ce9-4c07-8049-30a5538e3ef8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Startup warning cannot find files

[Sverre Moe]

It seems these are old builds, that no longer exists. We keep only the last 
N builds.
I have not checked all, but I think I can say that they all are probably 
from old builds that no longer exists.

søndag 7. april 2019 22.17.20 UTC+2 skrev Sverre Moe følgende:
>
> There was no more output. Just two lines of Warning, lots of them
>
> 2019.04.04 10:30.00 com.cloudbees.hudson.plugins.folder.AbstractFolder 
> loadChildren
> WARNING: Could not find file 
> /var/lib/jenkins/jobs/projectName/branches/branchName/config.xml
>
> søndag 7. april 2019 22.08.21 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>
>> Without the whole exception it is difficult to help you on something, 
>> however this error could be related to previous errors, you have to check 
>> the first exceptions in logs would be the real cause to cannot read files, 
>> also check the warnings and errors in manage Jenkins page, I bet you have 
>> plugins that failed to load for some break dependency, if so update your 
>> plugins is the solution.
>
>

-- 
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/263711ee-f95f-42b4-959b-dbed07e457bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Views in Blue Ocean

[Sverre Moe]

Has there been any consideration about getting Views in Blue Ocean?

The listing of pipelines becomes to large and distinct lists per view would 
be much better.
Having favourites does help, but just a little.
I want to see all projects under a certain git namespace. Also there are 
certain maintenance projects that I do not want to see listed (nor should 
regular users see those).

-- 
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/bd69b3da-baf8-4eb0-b737-681c41063636%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline with Staging builds before Release

[Sverre Moe]

Does anyone use Jenkins Pipeline with Staging?
To stage a build (hold it back) until some criteria has been met. No user 
interaction or manual process involved, fully automatic.


We have N Multibranch pipeline jobs in Jenkins with various dependencies on 
each other.
When building a release we need to verify it by building all downstream 
dependencies against this release.
So far so good. We get the list of all downstream dependencies.
Loop through them to build against this new release.

This new release must not be published to a release repository until the 
verification has succeeded.
If the verification fails, mark the build Unstable. Now those downstream 
dependencies are getting fixed and themself built.
They must be build with the artifacts from the previous unstable upstream 
project. Their build succeeds, their own verification also succeeds, but we 
cannot publish its artifacts yet either.
If we build a new release. We may need to build with all upstream 
dependencies that are not yet released, and if we do, then that build 
itself cannot be released.
It is the chicken and the egg problem.

My head hurts from trying to think out a solution to improve our Scripted 
Pipeline. Trying to redesign our pipeline flow and structure gives me a 
headache.

We have 4 stages: Checkout, Build, Verify, Publish.
A boiled down scripted Pipeline that represents how ours is:

def buildNodes = getBuildNodes()
def mainBuildNode = buildNodes.first()

stage("Checkout") {
node (mainBuildNode)
def scmProps = scm checkout
createArchive()
stash name: 'buildArchive', includes: *.tar.gz
}
}

stage("Build") {
   parallel doBuild(buildNodes)
}

def allUpstreamDependencies = getAllUpstreamDependencies()
def allDownstreamDependencies = getAllDownstreamDependencies()

stage("Verify") {
   parallel doVerify(buildNodes, allDownstreamDependencies)
}

stage("Publish") {
   parallel doPublish(buildNodes)
}

checkUpstreamAndStartBuild(allUpstreamDependencies)
checkDownstreamAndStartBuild(allDownstreamDependencies)

if (releaseBuild && verified)
doTagScmRelease()
}

The triggering of upstream and downstream projects works, but we have one 
remaining flaw. If a build succeeds and verifies, it will be published to 
release, even though It has an upstream dependencies that is in a failed 
state (not yet released).

We cannot be the only organization with such a complicated Pipeline. Can a 
Declarative Pipeline work better? We have a lot of pipeline code.
Any suggestions, ideas and tips is highly appreciated.

-- 
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/3cbbd251-4ab6-40dc-852d-32bcc8fa8be4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Blue Ocean: Hide certain projects from Pipelines

[Sverre Moe]

I found one workarround

Create a Folder Job. Move all Coverity jobs into this. And they will not be 
seen in Blue Ocean.

søndag 7. april 2019 00.07.54 UTC+2 skrev Sverre Moe følgende:
>
> Is it possible to not show certain pipelines in Blue Ocean.
>
> We have one coverity job for each project.
> ProjectA
> ProjectA_cov
> ProjectB
> ProjectB_cov
>
> This pollutes the Pipelines list in Blue Ocean. Is it possible to avoid 
> seing them.
> In Jenkins Classic, we have views where these projects are not visible.
>

-- 
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/eb8ee5cb-3101-415a-86f8-7088f97f089f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Blue Ocean: Hide certain projects from Pipelines

[Sverre Moe]

I rejoiced to soon. They did indeed show on Blue Ocean.
folder > job1_cov
folder > job2_cov

torsdag 11. april 2019 12.35.55 UTC+2 skrev Sverre Moe følgende:
>
> I found one workarround
>
> Create a Folder Job. Move all Coverity jobs into this. And they will not 
> be seen in Blue Ocean.
>
> søndag 7. april 2019 00.07.54 UTC+2 skrev Sverre Moe følgende:
>>
>> Is it possible to not show certain pipelines in Blue Ocean.
>>
>> We have one coverity job for each project.
>> ProjectA
>> ProjectA_cov
>> ProjectB
>> ProjectB_cov
>>
>> This pollutes the Pipelines list in Blue Ocean. Is it possible to avoid 
>> seing them.
>> In Jenkins Classic, we have views where these projects are not visible.
>>
>

-- 
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/da068b79-f92c-4d5e-bddd-57afd717c0a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Blue Ocean: Hide certain projects from Pipelines

[Sverre Moe]

Found this
https://issues.jenkins-ci.org/browse/JENKINS-39343

Seems there is planned some filtering feature to Blue Ocean.
It is Very Old issue. I really hope it will done soon.

torsdag 11. april 2019 12.42.40 UTC+2 skrev Sverre Moe følgende:
>
> I rejoiced to soon. They did indeed show on Blue Ocean.
> folder > job1_cov
> folder > job2_cov
>
> torsdag 11. april 2019 12.35.55 UTC+2 skrev Sverre Moe følgende:
>>
>> I found one workarround
>>
>> Create a Folder Job. Move all Coverity jobs into this. And they will not 
>> be seen in Blue Ocean.
>>
>> søndag 7. april 2019 00.07.54 UTC+2 skrev Sverre Moe følgende:
>>>
>>> Is it possible to not show certain pipelines in Blue Ocean.
>>>
>>> We have one coverity job for each project.
>>> ProjectA
>>> ProjectA_cov
>>> ProjectB
>>> ProjectB_cov
>>>
>>> This pollutes the Pipelines list in Blue Ocean. Is it possible to avoid 
>>> seing them.
>>> In Jenkins Classic, we have views where these projects are not visible.
>>>
>>

-- 
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/65435c0f-b2b2-4508-b9cd-e7307f5b4f48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Views in Blue Ocean

[Sverre Moe]

https://issues.jenkins-ci.org/browse/JENKINS-39343

mandag 8. april 2019 09.55.05 UTC+2 skrev Sverre Moe følgende:
>
> Has there been any consideration about getting Views in Blue Ocean?
>
> The listing of pipelines becomes to large and distinct lists per view 
> would be much better.
> Having favourites does help, but just a little.
> I want to see all projects under a certain git namespace. Also there are 
> certain maintenance projects that I do not want to see listed (nor should 
> regular users see those).
>

-- 
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/ca3fd754-b089-41b2-bf0e-94a551c03aca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins Slow when user not logged in

[Sverre Moe]

When a user is not logged in then loading Jenkins can be extremely slow.
Is this a known issue with Jenkins?

We are running Jenkins LTS 2.150.1.
Using LDAP authentication:
  Logged-in users can do anything, enabled anonymous read access.
Enabled Cache:
  Cache size 50
  Cache TTL 1 hour

-- 
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/47aa5954-a8ad-4102-bea9-106552cdc3ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Warnings Next Generation Plugin With GCC C++

[Sverre Moe]

How do I use this plugin to record and show C/C++ Warnings/Errors from GCC?

There is two tools available GNU C Compiler (gcc3) and GNU C Compiler 
(gcc4), but are those for C?
We are using a much newer version of GCC.

Otherwise I could only find these for C++
recordIssues(tools: [cppCheck()])
recordIssues(tools: [cppLint()])

Neither found no warnings, but there where plenty of warnings when running 
GCC.

[50/107] Building CXX object src/CMakeFiles/some.dir/thing/file.cpp.o 
src/thing/file.cpp: In member function ‘std::__cxx11::string file::method(const 
string&, const string&)’:

src/thing/file.cpp:141:31: warning: unused variable ‘id’ [-Wunused-variable]
 for (const auto & [ id, m ] : _id_to_var)



I tried with the gcc4, and it spewed out some errors with stacktrace in the 
recording. Looks like it tried to run some git commands, and I do not have a 
git repository at hand, just a stashed archive.

However it seems at least it did find some Warnings. The warning above was 
detected by gcc4.

Is there any way I can stop it from accessing Git when it is trying to record?

-- 
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/db195bc3-2907-4dee-8a4b-a9a1bf2c6734%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Warnings Next Generation Plugin With GCC C++

[Sverre Moe]

It seems to be very confused.
I am bulding on 4 nodes
opensuse42.3
opensuse15.0
sles12.3
sles15.0

They have each their own gcc4 ID, but they have the same result, showing 
the same 4 entries for each.
Total 5 
/dev/shm/rpmroot-build-opensuse42.3_x86_64/projectA/BUILD/projectA-1.3.2/something/some_thing_file
Total 6 
/dev/shm/rpmroot-build-opensuse15.0_x86_64/projectA/BUILD/projectA-1.3.2/src/dirA
Total 2 
/dev/shm/rpmroot-build-opensuse15.0_x86_64/projectA/BUILD/projectA-1.3.2/src/dirB
Total 10 
/dev/shm/rpmroot-build-opensuse15.0_x86_64/projectA/BUILD/projectA-1.3.2/something/some_thing_file

None from the sles nodes are shown.

mandag 6. mai 2019 12.27.29 UTC+2 skrev Sverre Moe følgende:
>
> How do I use this plugin to record and show C/C++ Warnings/Errors from GCC?
>
> There is two tools available GNU C Compiler (gcc3) and GNU C Compiler 
> (gcc4), but are those for C?
> We are using a much newer version of GCC.
>
> Otherwise I could only find these for C++
> recordIssues(tools: [cppCheck()])
> recordIssues(tools: [cppLint()])
>
> Neither found no warnings, but there where plenty of warnings when running 
> GCC.
>
> [50/107] Building CXX object src/CMakeFiles/some.dir/thing/file.cpp.o 
> src/thing/file.cpp: In member function ‘std::__cxx11::string 
> file::method(const string&, const string&)’:
>
> src/thing/file.cpp:141:31: warning: unused variable ‘id’ [-Wunused-variable]
>  for (const auto & [ id, m ] : _id_to_var)
>
>
>
> I tried with the gcc4, and it spewed out some errors with stacktrace in the 
> recording. Looks like it tried to run some git commands, and I do not have a 
> git repository at hand, just a stashed archive.
>
> However it seems at least it did find some Warnings. The warning above was 
> detected by gcc4.
>
> Is there any way I can stop it from accessing Git when it is trying to record?
>
>

-- 
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/781cdf80-3930-4f9f-8249-336532dedacd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Warnings Next Generation Plugin With GCC C++

[Sverre Moe]

mandag 6. mai 2019 12.55.15 UTC+2 skrev Ullrich Hafner følgende:
>
>
>
> I think I should rename the Tools
>
> GNU C Compiler (gcc4) -> GNU C Compiler 
> GNU C Compiler (gcc3) -> GNU C Compiler (3 and older)
>
> And the ID to gcc. 
>
> Would that make sense?
>
>
That makes sense. 

-- 
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/2539b872-fe24-484a-837f-3ba138368f05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Warnings Next Generation Plugin With GCC C++

[Sverre Moe]

I think the tool
Reads the complete output (where all 4 nodes are intermingled).
It would be better if it could read only for the one node it is executed 
within.

Still I find it odd that it showed the same issues for all nodes. It should 
at least show the ones from the node itself
sles12.3 output showed none of the sles12.3 warnings.

mandag 6. mai 2019 13.01.22 UTC+2 skrev Sverre Moe følgende:
>
> It seems to be very confused.
> I am bulding on 4 nodes
> opensuse42.3
> opensuse15.0
> sles12.3
> sles15.0
>
> They have each their own gcc4 ID, but they have the same result, showing 
> the same 4 entries for each.
> Total 5 
> /dev/shm/rpmroot-build-opensuse42.3_x86_64/projectA/BUILD/projectA-1.3.2/something/some_thing_file
> Total 6 
> /dev/shm/rpmroot-build-opensuse15.0_x86_64/projectA/BUILD/projectA-1.3.2/src/dirA
> Total 2 
> /dev/shm/rpmroot-build-opensuse15.0_x86_64/projectA/BUILD/projectA-1.3.2/src/dirB
> Total 10 
> /dev/shm/rpmroot-build-opensuse15.0_x86_64/projectA/BUILD/projectA-1.3.2/something/some_thing_file
>
> None from the sles nodes are shown.
>
> mandag 6. mai 2019 12.27.29 UTC+2 skrev Sverre Moe følgende:
>>
>> How do I use this plugin to record and show C/C++ Warnings/Errors from 
>> GCC?
>>
>> There is two tools available GNU C Compiler (gcc3) and GNU C Compiler 
>> (gcc4), but are those for C?
>> We are using a much newer version of GCC.
>>
>> Otherwise I could only find these for C++
>> recordIssues(tools: [cppCheck()])
>> recordIssues(tools: [cppLint()])
>>
>> Neither found no warnings, but there where plenty of warnings when 
>> running GCC.
>>
>> [50/107] Building CXX object src/CMakeFiles/some.dir/thing/file.cpp.o 
>> src/thing/file.cpp: In member function ‘std::__cxx11::string 
>> file::method(const string&, const string&)’:
>>
>> src/thing/file.cpp:141:31: warning: unused variable ‘id’ [-Wunused-variable]
>>  for (const auto & [ id, m ] : _id_to_var)
>>
>>
>>
>> I tried with the gcc4, and it spewed out some errors with stacktrace in the 
>> recording. Looks like it tried to run some git commands, and I do not have a 
>> git repository at hand, just a stashed archive.
>>
>> However it seems at least it did find some Warnings. The warning above was 
>> detected by gcc4.
>>
>> Is there any way I can stop it from accessing Git when it is trying to 
>> record?
>>
>>

-- 
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/86e41f89-fdc6-499d-8cad-3403128bad04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Warnings Next Generation Plugin With GCC C++

[Sverre Moe]

mandag 6. mai 2019 13.23.02 UTC+2 skrev Ullrich Hafner følgende:
>
> There are some open issues about that:
> https://issues.jenkins-ci.org/browse/JENKINS-44450
> https://issues.jenkins-ci.org/browse/JENKINS-55258
>
> As a workaround you should pipe the log to a file.
>
 
How so, is there a pipeline step to do this?
Or do I need to take the output from sh step?

-- 
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/7290124c-0624-4822-8595-16fb82a6774f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline: Show changes on build for rebased commits

[Sverre Moe]

Jenkins does not show changes after commits have been rebased.

Build #1: has 3 changes (commits)
Build #2: no changes

The second build actually has the same three changes. but these are not 
shown. They are same changes as before, but just slightly changed (git 
rebased).

I want the changes shown for the second build. Is this possible to enable?

-- 
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/f6bfe890-5c44-4d76-8349-1032dd9fa007%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: Show changes on build for rebased commits

[Sverre Moe]

In Blue Ocean, under Changes, getting "There are no changes for this run".
However there are changes. Is there no way I can force it to show the 
changes?

mandag 13. mai 2019 16.27.27 UTC+2 skrev Sverre Moe følgende:
>
> Jenkins does not show changes after commits have been rebased.
>
> Build #1: has 3 changes (commits)
> Build #2: no changes
>
> The second build actually has the same three changes. but these are not 
> shown. They are same changes as before, but just slightly changed (git 
> rebased).
>
> I want the changes shown for the second build. Is this possible to enable?
>

-- 
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/50507b11-dd0c-44cb-ba78-ae4cbc192584%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Pipelines: Use jx-release-version

[Sverre Moe]

I created a number of Issues on jx-release-version in GitHub.
https://github.com/jenkins-x/jx-release-version/issues

Just submitted a PR for an issue I reported:
https://github.com/jenkins-x/jx-release-version/pull/32

I also started to implement support for CMake, Automake and Gradle. The 
first two are finished and commited (not pushed yet), but I am waiting for 
my PR to be merged before I submit more PRs.

torsdag 7. mars 2019 20.58.40 UTC+1 skrev Sverre Moe følgende:
>
> I read the CloudBees blog on jx-release-version.
>>
>> x-release-version calculates the next version number based on the current 
>> Git tag, or current specified version on pom.xml/Makefile
>
>
> https://www.cloudbees.com/blog/automatically-versioning-your-application-jenkins-x
>
> It looks interesting to determine next version. Is it only available for 
> Jenkins X?
>
> We use something like automatic versioning based on the number of git 
> commits.
> Current version v1.0.0
> Add 5 commits, push and next version is v1.0.5
> This is because we didn't want to make bump commits any more.
> With this jx-release-version we could get the same advantage, but not get 
> the next version minor as a commit count from the last.
>
> Can this tool be used with standard Jenkins installation and our Pipeline 
> scripts?
>
> What about Gradle, automake and cmake? Is there plans to support these 
> also?
> build.gradle
> version = 1.0.0-SNAPSHOT
> CMakeLists.txt
> project(application VERSION 1.0.0)
> configure.ac
> AC_INIT(application, 1.0.0)
>
> Our projects with automake (configure.ac) and cmake (CMakeLists.txt) does 
> not use the SNAPSHOT postfix on version. It is only used for Java projects 
> with Maven and Gradle.
>

-- 
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/99b2d910-1883-4f65-a39e-792bab688b9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Running a Pipeline multiple times in parallel

[Sverre Moe]

Our build Scripted Pipeline have several stages each in parallel executions.

[image: Screenshot_20190521_181654.png]

I need to run two parallel Pipeline builds in the same Run.
I want this Stage view to duplicate and be run in parallel.

However my test parallel script does not look good in Blue Ocean. It is 
only one Stage.

[image: Screenshot_20190521_182645.png]


My test parallel Scripted Pipeline
parallel 'ReleaseA': {
stage("Checkout") {
println "Checkout"
}

stage("Build") {
parallel 'sles12.3-x86_64': {
println "Build"
}, 'sles15.0-x86_64': {
println "Build"
}
}

stage("Analysis") {
println "Analysis"
}

stage("Staging") {
parallel 'sles12.3-x86_64': {
println "Staging"
}, 'sles15.0-x86_64': {
println "Staging"
}
}

stage("Verify") {
parallel 'sles12.3-x86_64': {
println "Verify"
}, 'sles15.0-x86_64': {
println "Verify"
}
}

stage("Publish") {
parallel 'sles12.3-x86_64': {
println "Publish"
}, 'sles15.0-x86_64': {
println "Publish"
}   
}
}, 'ReleaseB': {
stage("Checkout") {
println "Checkout"
}

stage("Build") {
parallel 'sles12.3-x86_64': {
println "Build"
}, 'sles15.0-x86_64': {
println "Build"
}
}

stage("Analysis") {
println "Analysis"
}

stage("Staging") {
parallel 'sles12.3-x86_64': {
println "Staging"
}, 'sles15.0-x86_64': {
println "Staging"
}
}

stage("Verify") {
parallel 'sles12.3-x86_64': {
println "Verify"
}, 'sles15.0-x86_64': {
println "Verify"
}
}

stage("Publish") {
parallel 'sles12.3-x86_64': {
println "Publish"
}, 'sles15.0-x86_64': {
println "Publish"
}   
}
}


-- 
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/a0d4ee14-0121-4f74-8eac-bdb23a51696c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Warnings Next Generation Plugin: Keep its history after discard builds

[Sverre Moe]

The "Warnings Trend" graphs are empty.

>From out last build:
sles15.0-x86_64: No warnings
No warnings for 28 builds, i.e. since build 3

This might be because we delete old builds. We keep only the last 10 builds.
In this case build #3 has been deleted.

Is there a workaround for this? We do not want to keep all builds in Build 
History. As it requires much more disk space and (perhaps could slow down 
Jenkins ((a guess)).

-- 
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/1edbe937-2d9a-4dba-9a72-d4b567299bab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline: The sh step does not show all output

[Sverre Moe]

The standard output from the sh-step does not show all the output:
final def output = sh(returnStdout: true, label: "Build and Package", script
: "make")
writeFile(file: 'buildOutputFile.txt', text: output)

The Blue Ocean log output from a single Node shows all the warnings, but 
the output from the sh step does not:
https://JENKINS_URL/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0

Could it be that the actual output is not stdout, but stderr? Unfortunately 
sh does not have an returnStderr.

I am using this output for the Warnings Plugin, since I want warning for 
each build node, and the plugin default reads the entire console output.
recordIssues(tools: [gcc4(id: "gcc-${buildHost}", name: "${buildHost}", 
pattern: "buildOutputFile.txt")])

-- 
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/0d105336-5172-4a18-b071-e4641357a4d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: The sh step does not show all output

[Sverre Moe]

I found a way to ouput both stdout and stderr, but then I didn't get either 
in Jenkins Console.
sh("make 2>&1 | tee buildOutputFile.txt")

mandag 27. mai 2019 12.20.17 UTC+2 skrev Sverre Moe følgende:
>
> The standard output from the sh-step does not show all the output:
> final def output = sh(returnStdout: true, label: "Build and Package", 
> script: "make")
> writeFile(file: 'buildOutputFile.txt', text: output)
>
> The Blue Ocean log output from a single Node shows all the warnings, but 
> the output from the sh step does not:
>
> https://JENKINS_URL/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0
>
> Could it be that the actual output is not stdout, but stderr? 
> Unfortunately sh does not have an returnStderr.
>
> I am using this output for the Warnings Plugin, since I want warning for 
> each build node, and the plugin default reads the entire console output.
> recordIssues(tools: [gcc4(id: "gcc-${buildHost}", name: "${buildHost}", 
> pattern: "buildOutputFile.txt")])
>

-- 
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/5efbb0ab-54e9-462c-86f6-2ff0593a88fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: The sh step does not show all output

[Sverre Moe]

Not sure I understand that workaround.

"$@" 2>&1; echo $? >&3) | tee "$LOGFILE" >&4) 3>&1) | (read xs; exit $xs)) 
4>&1

I tried to modify this to work with my example:


final def output = sh(returnStdout: true, script: "make >&3) | tee 
buildOutput.txt >&4) 3>&1) | (read xs; exit $xs)) 4>&1")


Not quite sure how!


mandag 27. mai 2019 12.57.28 UTC+2 skrev Ullrich Hafner følgende:
>
> Would a workaround as shown in 
> https://issues.jenkins-ci.org/browse/JENKINS-54832 help?
>
> Am 27.05.2019 um 12:51 schrieb Sverre Moe 
> >:
>
> I found a way to ouput both stdout and stderr, but then I didn't get 
> either in Jenkins Console.
> sh("make 2>&1 | tee buildOutputFile.txt")
>
> mandag 27. mai 2019 12.20.17 UTC+2 skrev Sverre Moe følgende:
>>
>> The standard output from the sh-step does not show all the output:
>> final def output = sh(returnStdout: true, label: "Build and Package", 
>> script: "make")
>> writeFile(file: 'buildOutputFile.txt', text: output)
>>
>> The Blue Ocean log output from a single Node shows all the warnings, but 
>> the output from the sh step does not:
>>
>> https://JENKINS_URL/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0
>>  
>> <https://jenkins_url/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0>
>>
>> Could it be that the actual output is not stdout, but stderr? 
>> Unfortunately sh does not have an returnStderr.
>>
>> I am using this output for the Warnings Plugin, since I want warning for 
>> each build node, and the plugin default reads the entire console output.
>> recordIssues(tools: [gcc4(id: "gcc-${buildHost}", name: "${buildHost}", 
>> pattern: "buildOutputFile.txt")])
>>
>
> -- 
> 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/5efbb0ab-54e9-462c-86f6-2ff0593a88fa%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-users/5efbb0ab-54e9-462c-86f6-2ff0593a88fa%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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/17a84031-c584-4a8b-a5a5-309d21b0e46e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: The sh step does not show all output

[Sverre Moe]

I got it to work by modifying my original sh step. I had to remove 
returnStdout

sh(label: "Build and Package", script: "make 2>&1 | tee buildOutputFile.txt"
)



mandag 27. mai 2019 15.50.07 UTC+2 skrev Sverre Moe følgende:
>
> Not sure I understand that workaround.
>
> "$@" 2>&1; echo $? >&3) | tee "$LOGFILE" >&4) 3>&1) | (read xs; exit 
> $xs)) 4>&1
>
> I tried to modify this to work with my example:
>
>
> final def output = sh(returnStdout: true, script: "make >&3) | tee 
> buildOutput.txt >&4) 3>&1) | (read xs; exit $xs)) 4>&1")
>
>
> Not quite sure how!
>
>
> mandag 27. mai 2019 12.57.28 UTC+2 skrev Ullrich Hafner følgende:
>>
>> Would a workaround as shown in 
>> https://issues.jenkins-ci.org/browse/JENKINS-54832 help?
>>
>> Am 27.05.2019 um 12:51 schrieb Sverre Moe :
>>
>> I found a way to ouput both stdout and stderr, but then I didn't get 
>> either in Jenkins Console.
>> sh("make 2>&1 | tee buildOutputFile.txt")
>>
>> mandag 27. mai 2019 12.20.17 UTC+2 skrev Sverre Moe følgende:
>>>
>>> The standard output from the sh-step does not show all the output:
>>> final def output = sh(returnStdout: true, label: "Build and Package", 
>>> script: "make")
>>> writeFile(file: 'buildOutputFile.txt', text: output)
>>>
>>> The Blue Ocean log output from a single Node shows all the warnings, but 
>>> the output from the sh step does not:
>>>
>>> https://JENKINS_URL/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0
>>>  
>>> <https://jenkins_url/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0>
>>>
>>> Could it be that the actual output is not stdout, but stderr? 
>>> Unfortunately sh does not have an returnStderr.
>>>
>>> I am using this output for the Warnings Plugin, since I want warning for 
>>> each build node, and the plugin default reads the entire console output.
>>> recordIssues(tools: [gcc4(id: "gcc-${buildHost}", name: "${buildHost}", 
>>> pattern: "buildOutputFile.txt")])
>>>
>>
>> -- 
>> 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/5efbb0ab-54e9-462c-86f6-2ff0593a88fa%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/5efbb0ab-54e9-462c-86f6-2ff0593a88fa%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>

-- 
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/d92ff0fd-f8b3-4cdd-8203-9f7b56567798%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: The sh step does not show all output

[Sverre Moe]

This workaround gave me some problem with failing builds.
The step no longer is marked failed when it fails.

mandag 27. mai 2019 16.27.11 UTC+2 skrev Sverre Moe følgende:
>
> I got it to work by modifying my original sh step. I had to remove 
> returnStdout
>
> sh(label: "Build and Package", script: "make 2>&1 | tee 
> buildOutputFile.txt")
>
>
>
> mandag 27. mai 2019 15.50.07 UTC+2 skrev Sverre Moe følgende:
>>
>> Not sure I understand that workaround.
>>
>> "$@" 2>&1; echo $? >&3) | tee "$LOGFILE" >&4) 3>&1) | (read xs; exit 
>> $xs)) 4>&1
>>
>> I tried to modify this to work with my example:
>>
>>
>> final def output = sh(returnStdout: true, script: "make >&3) | tee 
>> buildOutput.txt >&4) 3>&1) | (read xs; exit $xs)) 4>&1")
>>
>>
>> Not quite sure how!
>>
>>
>> mandag 27. mai 2019 12.57.28 UTC+2 skrev Ullrich Hafner følgende:
>>>
>>> Would a workaround as shown in 
>>> https://issues.jenkins-ci.org/browse/JENKINS-54832 help?
>>>
>>> Am 27.05.2019 um 12:51 schrieb Sverre Moe :
>>>
>>> I found a way to ouput both stdout and stderr, but then I didn't get 
>>> either in Jenkins Console.
>>> sh("make 2>&1 | tee buildOutputFile.txt")
>>>
>>> mandag 27. mai 2019 12.20.17 UTC+2 skrev Sverre Moe følgende:
>>>>
>>>> The standard output from the sh-step does not show all the output:
>>>> final def output = sh(returnStdout: true, label: "Build and Package", 
>>>> script: "make")
>>>> writeFile(file: 'buildOutputFile.txt', text: output)
>>>>
>>>> The Blue Ocean log output from a single Node shows all the warnings, 
>>>> but the output from the sh step does not:
>>>>
>>>> https://JENKINS_URL/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0
>>>>  
>>>> <https://jenkins_url/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0>
>>>>
>>>> Could it be that the actual output is not stdout, but stderr? 
>>>> Unfortunately sh does not have an returnStderr.
>>>>
>>>> I am using this output for the Warnings Plugin, since I want warning 
>>>> for each build node, and the plugin default reads the entire console 
>>>> output.
>>>> recordIssues(tools: [gcc4(id: "gcc-${buildHost}", name: "${buildHost}", 
>>>> pattern: "buildOutputFile.txt")])
>>>>
>>>
>>> -- 
>>> 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/5efbb0ab-54e9-462c-86f6-2ff0593a88fa%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/5efbb0ab-54e9-462c-86f6-2ff0593a88fa%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>

-- 
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/1af99929-9178-4181-8d54-9ab38b79a2d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline: OutOfMemoryError on build sh step

[Sverre Moe]

What is the usual culprit of this OutOfMemory problem?
It happened at a "sh" step.

It says nothing about HEAP or PermGen.
My Jenkins has 8GB of MaxHeap, and are only now using 6GB.
Running Jenkins LTS 2.150.1

java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at hudson.Proc$LocalProc.(Proc.java:269)
at hudson.Proc$LocalProc.(Proc.java:218)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:936)
at hudson.Launcher$ProcStarter.start(Launcher.java:455)
at 
org.jenkinsci.plugins.durabletask.BourneShellScript.launchWithCookie(BourneShellScript.java:206)
at 
org.jenkinsci.plugins.durabletask.FileMonitoringTask.launch(FileMonitoringTask.java:99)
at 
org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.start(DurableTaskStep.java:305)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:268)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:176)
at 
org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
at 
org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)
at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at 
com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:20)
at 
no.spacetec.ci.Publish.transformIntoStep(file:/var/lib/jenkins/jobs/projectA/branches/user-development.tj51jn/builds/69/libs/pipeline/src/no/company/ci/Publish.groovy:217)
at ___cps.transform___(Native Method)
at 
com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
at sun.reflect.GeneratedMethodAccessor343.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at 
com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.dispatch(CollectionLiteralBlock.java:55)
at 
com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.item(CollectionLiteralBlock.java:45)
at sun.reflect.GeneratedMethodAccessor336.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:103)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
at sun.reflect.GeneratedMethodAccessor343.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at 
com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:60)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
at sun.reflect.GeneratedMethodAccessor343.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at 
com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
at com.cloudbees.groovy.cps.Next.step(Next.java:83)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
at 
org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
at 
org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
at 
org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$101(SandboxContinuable.java:34)
at 
org.jenkinsci.p

Re: Pipeline: The sh step does not show all output

[Sverre Moe]

I did not set such a parameter

Like so?
sh("set -o pipefail\n commandA | commandB")

fredag 31. mai 2019 13.41.50 UTC+2 skrev Baptiste Mathus følgende:
>
> Likely because when calling scripts this way, `set -o pipefail` is not set 
> maybe?
>
> Le ven. 31 mai 2019 à 10:06, Sverre Moe > 
> a écrit :
>
>> This workaround gave me some problem with failing builds.
>> The step no longer is marked failed when it fails.
>>
>> mandag 27. mai 2019 16.27.11 UTC+2 skrev Sverre Moe følgende:
>>>
>>> I got it to work by modifying my original sh step. I had to remove 
>>> returnStdout
>>>
>>> sh(label: "Build and Package", script: "make 2>&1 | tee 
>>> buildOutputFile.txt")
>>>
>>>
>>>
>>> mandag 27. mai 2019 15.50.07 UTC+2 skrev Sverre Moe følgende:
>>>>
>>>> Not sure I understand that workaround.
>>>>
>>>> "$@" 2>&1; echo $? >&3) | tee "$LOGFILE" >&4) 3>&1) | (read xs; exit 
>>>> $xs)) 4>&1
>>>>
>>>> I tried to modify this to work with my example:
>>>>
>>>>
>>>> final def output = sh(returnStdout: true, script: "((((make >&3) | tee 
>>>> buildOutput.txt >&4) 3>&1) | (read xs; exit $xs)) 4>&1")
>>>>
>>>>
>>>> Not quite sure how!
>>>>
>>>>
>>>> mandag 27. mai 2019 12.57.28 UTC+2 skrev Ullrich Hafner følgende:
>>>>>
>>>>> Would a workaround as shown in 
>>>>> https://issues.jenkins-ci.org/browse/JENKINS-54832 help?
>>>>>
>>>>> Am 27.05.2019 um 12:51 schrieb Sverre Moe :
>>>>>
>>>>> I found a way to ouput both stdout and stderr, but then I didn't get 
>>>>> either in Jenkins Console.
>>>>> sh("make 2>&1 | tee buildOutputFile.txt")
>>>>>
>>>>> mandag 27. mai 2019 12.20.17 UTC+2 skrev Sverre Moe følgende:
>>>>>>
>>>>>> The standard output from the sh-step does not show all the output:
>>>>>> final def output = sh(returnStdout: true, label: "Build and Package",
>>>>>>  script: "make")
>>>>>> writeFile(file: 'buildOutputFile.txt', text: output)
>>>>>>
>>>>>> The Blue Ocean log output from a single Node shows all the warnings, 
>>>>>> but the output from the sh step does not:
>>>>>>
>>>>>> https://JENKINS_URL/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0
>>>>>>  
>>>>>> <https://jenkins_url/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0>
>>>>>>
>>>>>> Could it be that the actual output is not stdout, but stderr? 
>>>>>> Unfortunately sh does not have an returnStderr.
>>>>>>
>>>>>> I am using this output for the Warnings Plugin, since I want warning 
>>>>>> for each build node, and the plugin default reads the entire console 
>>>>>> output.
>>>>>> recordIssues(tools: [gcc4(id: "gcc-${buildHost}", name: 
>>>>>> "${buildHost}", pattern: "buildOutputFile.txt")])
>>>>>>
>>>>>
>>>>> -- 
>>>>> 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/5efbb0ab-54e9-462c-86f6-2ff0593a88fa%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/5efbb0ab-54e9-462c-86f6-2ff0593a88fa%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>>
>>>>> -- 
>> 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/1af99929-9178-4181-8d54-9ab38b79a2d7%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/1af99929-9178-4181-8d54-9ab38b79a2d7%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/d1b02489-57f0-4a2d-9884-847c7803c4d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: The sh step does not show all output

[Sverre Moe]

Tried various solutions.
Settled with this which works:

sh(label: "Build and Package", script: """
set -o pipefail
make 2>&1 | tee buildOutputFile.txt
""")



fredag 31. mai 2019 13.50.23 UTC+2 skrev Sverre Moe følgende:
>
> I did not set such a parameter
>
> Like so?
> sh("set -o pipefail\n commandA | commandB")
>
> fredag 31. mai 2019 13.41.50 UTC+2 skrev Baptiste Mathus følgende:
>>
>> Likely because when calling scripts this way, `set -o pipefail` is not 
>> set maybe?
>>
>> Le ven. 31 mai 2019 à 10:06, Sverre Moe  a écrit :
>>
>>> This workaround gave me some problem with failing builds.
>>> The step no longer is marked failed when it fails.
>>>
>>> mandag 27. mai 2019 16.27.11 UTC+2 skrev Sverre Moe følgende:
>>>>
>>>> I got it to work by modifying my original sh step. I had to remove 
>>>> returnStdout
>>>>
>>>> sh(label: "Build and Package", script: "make 2>&1 | tee 
>>>> buildOutputFile.txt")
>>>>
>>>>
>>>>
>>>> mandag 27. mai 2019 15.50.07 UTC+2 skrev Sverre Moe følgende:
>>>>>
>>>>> Not sure I understand that workaround.
>>>>>
>>>>> "$@" 2>&1; echo $? >&3) | tee "$LOGFILE" >&4) 3>&1) | (read xs; exit 
>>>>> $xs)) 4>&1
>>>>>
>>>>> I tried to modify this to work with my example:
>>>>>
>>>>>
>>>>> final def output = sh(returnStdout: true, script: "make >&3) | tee 
>>>>> buildOutput.txt >&4) 3>&1) | (read xs; exit $xs)) 4>&1")
>>>>>
>>>>>
>>>>> Not quite sure how!
>>>>>
>>>>>
>>>>> mandag 27. mai 2019 12.57.28 UTC+2 skrev Ullrich Hafner følgende:
>>>>>>
>>>>>> Would a workaround as shown in 
>>>>>> https://issues.jenkins-ci.org/browse/JENKINS-54832 help?
>>>>>>
>>>>>> Am 27.05.2019 um 12:51 schrieb Sverre Moe :
>>>>>>
>>>>>> I found a way to ouput both stdout and stderr, but then I didn't get 
>>>>>> either in Jenkins Console.
>>>>>> sh("make 2>&1 | tee buildOutputFile.txt")
>>>>>>
>>>>>> mandag 27. mai 2019 12.20.17 UTC+2 skrev Sverre Moe følgende:
>>>>>>>
>>>>>>> The standard output from the sh-step does not show all the output:
>>>>>>> final def output = sh(returnStdout: true, label: "Build and Package"
>>>>>>> , script: "make")
>>>>>>> writeFile(file: 'buildOutputFile.txt', text: output)
>>>>>>>
>>>>>>> The Blue Ocean log output from a single Node shows all the warnings, 
>>>>>>> but the output from the sh step does not:
>>>>>>>
>>>>>>> https://JENKINS_URL/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0
>>>>>>>  
>>>>>>> <https://jenkins_url/blue/rest/organizations/jenkins/pipelines/PROJECT/branches/BRANCH/runs/2/nodes/56/log/?start=0>
>>>>>>>
>>>>>>> Could it be that the actual output is not stdout, but stderr? 
>>>>>>> Unfortunately sh does not have an returnStderr.
>>>>>>>
>>>>>>> I am using this output for the Warnings Plugin, since I want warning 
>>>>>>> for each build node, and the plugin default reads the entire console 
>>>>>>> output.
>>>>>>> recordIssues(tools: [gcc4(id: "gcc-${buildHost}", name: 
>>>>>>> "${buildHost}", pattern: "buildOutputFile.txt")])
>>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> 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/5efbb0ab-54e9-462c-86f6-2ff0593a88fa%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/5efbb0ab-54e9-462c-86f6-2ff0593a88fa%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>>
>>>>>> -- 
>>> 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/1af99929-9178-4181-8d54-9ab38b79a2d7%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/1af99929-9178-4181-8d54-9ab38b79a2d7%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
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/155b75e8-158a-4be3-8986-c39a9f8669d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: The sh step does not show all output

[Sverre Moe]

Marvelous, thanks, I'll try that.

fredag 31. mai 2019 18.20.28 UTC+2 skrev Daniel Saier følgende:
>
> You can also use the tee step 
> ,
>  
> which automatically propagates the return codes of the steps inside of the 
> tee.
>

-- 
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/897e6976-2821-498a-95cb-58f6131480a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline: Automatic gpg signing

[Sverre Moe]

I am trying to sign our RPM packages built on Jenkins. However it fails, 
probably because it asks for the passphrase.

gpg: signing failed: Inappropriate ioctl for device
error: gpg exec failed (2)

Sometimes it works for a little while when I have signed manually in the 
console.
When I sign manually I get to enter the passphrase in an ncurses input. 
Maybe it caches this for some times and therefore it works in Jenkins for 
that time period.

Is there anyway I can provide the passphrase using withCredentials?

-- 
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/6ae6dc2a-2714-4269-bf36-faa45c9d51fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: Automatic gpg signing

[Sverre Moe]

I have tried using something similar, but running it the ncurses passphrase 
dialog still comes up.

søndag 2. juni 2019 19.19.24 UTC+2 skrev Marky Jackson følgende:
>
> In previous lives I have seen the use of rpm-sign.exp files use to handle 
> this. Something like:
>
> #!/usr/bin/expect -f
>
> ### rpm-sign.exp -- Sign RPMs by sending the passphrase.
>
> spawn rpm --define "_gpg_name xxx" --addsign {*}$argv
> expect -exact "Enter pass phrase: "
> send -- "Secret passphrase\r"
> # or send {GPGPASSWORD}
> expect eof
>
> ## end of rpm-sign.exp
>
>
>
> On Sunday, June 2, 2019 at 6:04:35 AM UTC-7, Sverre Moe wrote:
>>
>> I am trying to sign our RPM packages built on Jenkins. However it fails, 
>> probably because it asks for the passphrase.
>>
>> gpg: signing failed: Inappropriate ioctl for device
>> error: gpg exec failed (2)
>>
>> Sometimes it works for a little while when I have signed manually in the 
>> console.
>> When I sign manually I get to enter the passphrase in an ncurses input. 
>> Maybe it caches this for some times and therefore it works in Jenkins for 
>> that time period.
>>
>> Is there anyway I can provide the passphrase using withCredentials?
>>
>

-- 
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/4fce86e9-405f-489e-9614-f0a6c2a660fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Multiple resources with same name not working

[Sverre Moe]

I have created a read-write resource lock

master-sles12.3-read
SLES 12.3 repository for master build environment #1
Labels master-sles12.3-write

master-sles12.3-read
SLES 12.3 repository for master build environment #2
Labels master-sles12.3-write

master-sles12.3-read
SLES 12.3 repository for master build environment #3
Labels master-sles12.3-write

I want the builds to acquire up to three read, on three concurrent builds. 
While with write all read should be locked.
I have three build nodes with the Label "master-sles12.3" which I am using 
for  the lock name.

final def repositoryResourceLock = OS + "-read"
lock(repositoryResourceLock) {
  ...
}

However, when one build has acquired the lock of "master-sles12.3-read", 
the other build cannot get a lock.
Found 0 available resource(s). Waiting for correct amount: 1.
[master-sles12.3-read] is locked, waiting...

-- 
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/af053486-179f-422b-84d2-2db082c7fc0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline: Shell step oddity removes escaped slash

[Sverre Moe]

I have the following Pipeline step to find specific files:
sh("find . -regex '.*${packageName}-[0-9.]+-.\\.noarch\\.rpm'")

The Output:
[Pipeline] sh
+ find . -regex '.*package-name-[0-9.]+-.\.noarch\.rpm'
This does not return any result.

Both of these two works in Bash:
find . -regex '.*meos-dashboard-[0-9.]+-.\.x86_64\.rpm'
find . -regex .*meos-dashboard-[0-9.]+-.\.x86_64\.rpm

This groovy code work:
def find = "find . -regex .*package-name-[0-9.]+-.\\.noarch\\.rpm".execute()
println find.text

This groovy code does not work:
def find = "find . -regex '.*package-name-[0-9.]+-.\\.noarch\\.rpm'".execute
()
println find.text


So it seems Groovy does not work with surrounding the regex with single 
quote. Trying without does not go so well either:
sh("find . -regex .*${packageName}-[0-9.]+-.\\.noarch\\.rpm")

The output:
[Pipeline] sh
+ find . -regex '.*package-name-[0-9.]+-..noarch.rpm'
Pipeline seems to remove the "\" from the regular expression when I am not 
using the single quote.


Any idea what is the problem here? Pipeline or Groovy?

-- 
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/a8a22c0b-d707-4fdc-b41c-91e8b12d756a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Performance loading slow

[Sverre Moe]

Seems there has been some improvements in a new version of Jenkins. Much 
better, but not quite out of the woods yet.
Upgrading to 2.181 seems to solve the slowness loading problem.

Let me repeat some of my comments from the Jenkins issue:
https://issues.jenkins-ci.org/browse/JENKINS-56243

I have been trying Jenkins 2.181 on our Jenkins Test server. Really fast 
loading of UI, not seeing any slowness.
Though the Jenkins Test server does not have as much build history, the 
real test would be to upgrade our Jenkins Production server.

Opening a multibranch project branch, the page seems to have loaded 
completely, but loading is still ongoing for some more ~30 seconds. Looked 
at what was loading and seems to be prototype.js. There was an fix for this 
in JENKINS-49319, but it was reverted.
Firefox is having much more problems than browsers with the Chromium 
engine. So it seems to be a javascript problem that last loading.

What I find very odd. If I log in to Jenkins (using LDAP) all loading 
problems goes away. Why should logging in solve the loading slowness?

The last remaining loading on Multibranch Pipeline branch project. 
Developer Tools in my browser showed me what was remaining trying to load.
ajax 200 xhr prototype.js:1585 310 B 15 ms
runs?since=%232&fullStages=true&_=1561103938220 200 xhr jquery2.js:998 48.8 
KB 18 ms
These two repeated several times for about 30+ seconds until the page was 
actually finished loading.

onsdag 20. mars 2019 19.05.51 UTC+1 skrev Sverre Moe følgende:
>
> I did try to delete the cookies from Jenkins, and it became much faster at 
> loading.
>
> onsdag 20. mars 2019 15.22.52 UTC+1 skrev Sverre Moe følgende:
>>
>> I tried increasing the cache
>> Size 50
>> TTL 1 hour
>>
>> Still loading is really slow for some.
>> Refresh main page, fast. Then I try to enter a project. and I click and 
>> click and click, wait and wait, but nothing. Then it just loads after 
>> several seconds.
>>
>> onsdag 20. mars 2019 15.16.03 UTC+1 skrev Sverre Moe følgende:
>>>
>>> The LDAP caching is supposed to increase performance
>>>
>>> > Some LDAP servers may be slow, or rate limit client requests. In such 
>>> cases enabling caching may improve performance of Jenkins with the risk of 
>>> delayed propagation of user changes from LDAP and increased memory usage on 
>>> the master. 
>>>
>>> onsdag 20. mars 2019 15.15.14 UTC+1 skrev Sverre Moe følgende:
>>>>
>>>> We have enabled cache for LDAP authentication
>>>> Cache size 20
>>>> Cache TTL 5 min 0 sec
>>>>
>>>>
>>>> Is there a workaround? Disabling cache perhaps?
>>>>
>>>> onsdag 20. mars 2019 00.03.01 UTC+1 skrev Stuart Rowe følgende:
>>>>>
>>>>> Since you have the Active Directory plugin installed, can you confirm 
>>>>> that you have caching enabled? We were bit by this when upgrading a test 
>>>>> instance to LTS 2.150.2.
>>>>> See: https://issues.jenkins-ci.org/browse/JENKINS-56243
>>>>>
>>>>

-- 
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/09cd3897-a119-41ab-b5cd-f72f795a4137%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Memory issues with Jenkins

[Sverre Moe]

We have assigned 8GB of memory to our Jenkins instance.
JAVA_OPTIONS=-Xmx8g

Still we experience memory issues after a while running.
java.lang.OutOfMemoryError: unable to create new native thread

We have:
aprox 40 connected build agents
aprox 400 pipeline jobs

We have a test Jenkins instance running with the same jobs, this one 
connects to the same build agents (though on a different home directory).

Lately we have been getting disconnected build agents, that we cannot get 
up again without restarting Jenkins.

Can we assign more memory to a build agent? Would it have any affect on 
this issue?

This we got from one of our latest Pipeline builds that failed on a 
sh("find  -exec ***") step. It failed on that build agent that is now 
disconnected.


java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at 
java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
at 
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1368)
at java.lang.UNIXProcess.initStreams(UNIXProcess.java:288)
at java.lang.UNIXProcess.lambda$new$2(UNIXProcess.java:258)
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:257)
at java.lang.ProcessImpl.start(ProcessImpl.java:134)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
at hudson.Proc$LocalProc.(Proc.java:249)
Also:   java.io.IOException: error=11, Resource temporarily unavailable




SEVERE: Unexpected error when retrieving changeset 
hudson.plugins.git.GitException: Error: git whatchanged --no-abbrev -M 
"--format=commit %H%ntree %T%nparent %P%nauthor %aN <%aE> % 
ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b" -n 1 
b2c871830a03ea5f2fd2b21245afb09d51d69686 in /home/build/jenkins/workspace/ 
project_user_work 
   at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$6.execute(CliGitAPIImpl.java:1012)
 

   at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
 

   at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
 

   at hudson.remoting.UserRequest.perform(UserRequest.java:212) 
   at hudson.remoting.UserRequest.perform(UserRequest.java:54) 
   at hudson.remoting.Request$2.run(Request.java:369) 
   at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
 

   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
   at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 

   at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 

   at java.lang.Thread.run(Thread.java:748)
   Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call 
to master-sles12.3-x86_64_3 
   at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) 
   at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) 

   at hudson.remoting.Channel.call(Channel.java:955) 
   at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
 

   at sun.reflect.GeneratedMethodAccessor678.invoke(Unknown 
Source) 
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 

   at java.lang.reflect.Method.invoke(Method.java:498) 
   at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
 

   at com.sun.proxy.$Proxy104.execute(Unknown Source) 
   at 
io.jenkins.blueocean.autofavorite.FavoritingScmListener.getChangeSet(FavoritingScmListener.java:159)
 

   at 
io.jenkins.blueocean.autofavorite.FavoritingScmListener.onCheckout(FavoritingScmListener.java:84)
 

   at 
org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:140) 
   at 
org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93)
 

   at 
org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80)
 

   at 
org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingS
tepExecution.java:47)

Jul 01, 2019 11:51:12 AM 
hudson.init.impl.InstallUncaughtExceptionHandler$DefaultUncaughtExceptionHandler
 
uncaughtException 
SEVERE: A thread (Timer-9692/39) died unexpectedly due to an uncaught 
exception, this may leave your Jenkins in a bad way and 
is usually indicative of a bug in the code. 
java.lang.OutOfMemoryError: unable to create new native thread 
  

Re: Memory issues with Jenkins

[Sverre Moe]

Today it has been chaotic.
Several build agents disconnected

Unexpected termination of the channel

Many builds failed because of Memory error.

I have tried restarting Jenkins several times today.

Anyone have any suggestions?

tirsdag 2. juli 2019 14.34.25 UTC+2 skrev Sverre Moe følgende:
>
> We have assigned 8GB of memory to our Jenkins instance.
> JAVA_OPTIONS=-Xmx8g
>
> Still we experience memory issues after a while running.
> java.lang.OutOfMemoryError: unable to create new native thread
>
> We have:
> aprox 40 connected build agents
> aprox 400 pipeline jobs
>
> We have a test Jenkins instance running with the same jobs, this one 
> connects to the same build agents (though on a different home directory).
>
> Lately we have been getting disconnected build agents, that we cannot get 
> up again without restarting Jenkins.
>
> Can we assign more memory to a build agent? Would it have any affect on 
> this issue?
>
> This we got from one of our latest Pipeline builds that failed on a 
> sh("find  -exec ***") step. It failed on that build agent that is now 
> disconnected.
>
>
> java.lang.OutOfMemoryError: unable to create new native thread
>   at java.lang.Thread.start0(Native Method)
>   at java.lang.Thread.start(Thread.java:714)
>   at 
> java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
>   at 
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1368)
>   at java.lang.UNIXProcess.initStreams(UNIXProcess.java:288)
>   at java.lang.UNIXProcess.lambda$new$2(UNIXProcess.java:258)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.lang.UNIXProcess.(UNIXProcess.java:257)
>   at java.lang.ProcessImpl.start(ProcessImpl.java:134)
>   at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
>   at hudson.Proc$LocalProc.(Proc.java:249)
> Also:   java.io.IOException: error=11, Resource temporarily unavailable
>
>
>
>
> SEVERE: Unexpected error when retrieving changeset 
> hudson.plugins.git.GitException: Error: git whatchanged --no-abbrev -M 
> "--format=commit %H%ntree %T%nparent %P%nauthor %aN <%aE> % 
> ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b" -n 1 
> b2c871830a03ea5f2fd2b21245afb09d51d69686 in /home/build/jenkins/workspace/ 
> project_user_work 
>at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$6.execute(CliGitAPIImpl.java:1012)
>  
>
>at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
>  
>
>at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
>  
>
>at hudson.remoting.UserRequest.perform(UserRequest.java:212) 
>at hudson.remoting.UserRequest.perform(UserRequest.java:54) 
>at hudson.remoting.Request$2.run(Request.java:369) 
>at 
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>  
>
>at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
>at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  
>
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  
>
>at java.lang.Thread.run(Thread.java:748)
>Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call 
> to master-sles12.3-x86_64_3 
>at 
> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) 
>at 
> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) 
>
>at hudson.remoting.Channel.call(Channel.java:955) 
>at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
>  
>
>at sun.reflect.GeneratedMethodAccessor678.invoke(Unknown 
> Source) 
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
>
>at java.lang.reflect.Method.invoke(Method.java:498) 
>at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
>  
>
>at com.sun.proxy.$Proxy104.execute(Unknown Source) 
>at 
> io.jenkins.blueocean.autofavorite.FavoritingScmListener.getChangeSet(FavoritingScmListener.java:159)
>  
>
>at 
> io.jenkins.blueocean.autofavorite.FavoritingScmListener.onCheckout(FavoritingScmListener.java:84)

Jenkins Agents getting disconnected

[Sverre Moe]

Lately we have experienced disconnected Agents.
Running Jenkins LTS 2.150.1
Java 8u181. Same for both Jenkins server and all build agents.

Looking at the log it shows this:

ERROR: [07/04/19 14:47:18] [SSH] Error deleting file. 
java.util.concurrent.TimeoutException 
at java.util.concurrent.FutureTask.get(FutureTask.java:205) 
at 
hudson.plugins.sshslaves.SSHLauncher.tearDownConnectionImpl(SSHLauncher.java:989)
 
at 
hudson.plugins.sshslaves.SSHLauncher.tearDownConnection(SSHLauncher.java:930) 
at 
hudson.plugins.sshslaves.SSHLauncher.afterDisconnect(SSHLauncher.java:925) 
at hudson.slaves.SlaveComputer$3.run(SlaveComputer.java:738) 
at 
jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
 
at 
jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
 
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748)

Relaunching the agent does not work. It just hangs.

I have no problem ssh into the agent server from the Jenkins server.

The only thing that works is restarting Jenkins. We have to do this several 
times per day now.

-- 
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/c9d2b342-be51-4f7f-82ad-c4098749fe4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Agents getting disconnected

[Sverre Moe]

On the build agents that gets disconnected there is plenty of available 
disk space.

When there are trying to connect, there are no remoting.jar java process on 
the agent running.

lørdag 6. juli 2019 22.59.31 UTC+2 skrev Karan Kaushik følgende:
>
> Hi
>
> We had been facing the same issue with Jenkins agent, one thing I remember 
> doing was managing the space on the jenkins agent, the disconnect could 
> happen due to no space remaining on agent machine.
>

-- 
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/22fe9b83-c585-4f1a-8346-471e395ffbce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Memory issues with Jenkins

[Sverre Moe]

I will try turning on GC logging.

torsdag 4. juli 2019 23.04.55 UTC+2 skrev Baptiste Mathus følgende:
>
> Did you enable GC logging to have a better understanding of the profile of 
> your memory consumption? If not, I would recommend you do it first and 
> analyze them.
> https://jenkins.io/blog/2016/11/21/gc-tuning/ explained this part (and 
> much more) quite well.
>
> Then, once you understand better when it crashes, possibly you'll want to 
> analyze a heap dump to see what is causing the problem.
>
> Cheers
>
>
> Le mar. 2 juil. 2019 à 15:30, Sverre Moe > 
> a écrit :
>
>> Today it has been chaotic.
>> Several build agents disconnected
>>
>> Unexpected termination of the channel
>>
>> Many builds failed because of Memory error.
>>
>> I have tried restarting Jenkins several times today.
>>
>> Anyone have any suggestions?
>>
>> tirsdag 2. juli 2019 14.34.25 UTC+2 skrev Sverre Moe følgende:
>>>
>>> We have assigned 8GB of memory to our Jenkins instance.
>>> JAVA_OPTIONS=-Xmx8g
>>>
>>> Still we experience memory issues after a while running.
>>> java.lang.OutOfMemoryError: unable to create new native thread
>>>
>>> We have:
>>> aprox 40 connected build agents
>>> aprox 400 pipeline jobs
>>>
>>> We have a test Jenkins instance running with the same jobs, this one 
>>> connects to the same build agents (though on a different home directory).
>>>
>>> Lately we have been getting disconnected build agents, that we cannot 
>>> get up again without restarting Jenkins.
>>>
>>> Can we assign more memory to a build agent? Would it have any affect on 
>>> this issue?
>>>
>>> This we got from one of our latest Pipeline builds that failed on a 
>>> sh("find  -exec ***") step. It failed on that build agent that is now 
>>> disconnected.
>>>
>>>
>>> java.lang.OutOfMemoryError: unable to create new native thread
>>> at java.lang.Thread.start0(Native Method)
>>> at java.lang.Thread.start(Thread.java:714)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1368)
>>> at java.lang.UNIXProcess.initStreams(UNIXProcess.java:288)
>>> at java.lang.UNIXProcess.lambda$new$2(UNIXProcess.java:258)
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> at java.lang.UNIXProcess.(UNIXProcess.java:257)
>>> at java.lang.ProcessImpl.start(ProcessImpl.java:134)
>>> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
>>> at hudson.Proc$LocalProc.(Proc.java:249)
>>> Also:   java.io.IOException: error=11, Resource temporarily unavailable
>>>
>>>
>>>
>>>
>>> SEVERE: Unexpected error when retrieving changeset 
>>> hudson.plugins.git.GitException: Error: git whatchanged --no-abbrev -M 
>>> "--format=commit %H%ntree %T%nparent %P%nauthor %aN <%aE> % 
>>> ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b" -n 1 
>>> b2c871830a03ea5f2fd2b21245afb09d51d69686 in /home/build/jenkins/workspace/ 
>>> project_user_work 
>>>at 
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$6.execute(CliGitAPIImpl.java:1012)
>>>  
>>>
>>>at 
>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
>>>  
>>>
>>>at 
>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
>>>  
>>>
>>>at hudson.remoting.UserRequest.perform(UserRequest.java:212) 
>>>at hudson.remoting.UserRequest.perform(UserRequest.java:54) 
>>>at hudson.remoting.Request$2.run(Request.java:369) 
>>>at 
>>> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>>>  
>>>
>>>at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
>>>at 
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>  
>>>
>>>at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>  
>>>
>>>at java.l

Re: Memory issues with Jenkins

[Sverre Moe]

Since we don't use 32bit, the reason must be
- the virtual memory of the OS has been fully depleted

How can I check for this, and remedy it?

fredag 5. juli 2019 03.17.38 UTC+2 skrev Jan Monterrubio følgende:

> Correct me if I’m wrong but I don’t think increasing heap size will 
> actually affect your ability to create more native threads. 
>
> See this for a possible explanation: 
> https://plumbr.io/outofmemoryerror/unable-to-create-new-native-thread
>
> On Thu, Jul 4, 2019 at 16:03 Baptiste Mathus  > wrote:
>
>> Did you enable GC logging to have a better understanding of the profile 
>> of your memory consumption? If not, I would recommend you do it first and 
>> analyze them.
>> https://jenkins.io/blog/2016/11/21/gc-tuning/ explained this part (and 
>> much more) quite well.
>>
>> Then, once you understand better when it crashes, possibly you'll want to 
>> analyze a heap dump to see what is causing the problem.
>>
>> Cheers
>>
>>
>> Le mar. 2 juil. 2019 à 15:30, Sverre Moe > 
>> a écrit :
>>
>>> Today it has been chaotic.
>>> Several build agents disconnected
>>>
>>> Unexpected termination of the channel
>>>
>>> Many builds failed because of Memory error.
>>>
>>> I have tried restarting Jenkins several times today.
>>>
>>> Anyone have any suggestions?
>>>
>>> tirsdag 2. juli 2019 14.34.25 UTC+2 skrev Sverre Moe følgende:
>>>>
>>>> We have assigned 8GB of memory to our Jenkins instance.
>>>> JAVA_OPTIONS=-Xmx8g
>>>>
>>>> Still we experience memory issues after a while running.
>>>> java.lang.OutOfMemoryError: unable to create new native thread
>>>>
>>>> We have:
>>>> aprox 40 connected build agents
>>>> aprox 400 pipeline jobs
>>>>
>>>> We have a test Jenkins instance running with the same jobs, this one 
>>>> connects to the same build agents (though on a different home directory).
>>>>
>>>> Lately we have been getting disconnected build agents, that we cannot 
>>>> get up again without restarting Jenkins.
>>>>
>>>> Can we assign more memory to a build agent? Would it have any affect on 
>>>> this issue?
>>>>
>>>> This we got from one of our latest Pipeline builds that failed on a 
>>>> sh("find  -exec ***") step. It failed on that build agent that is now 
>>>> disconnected.
>>>>
>>>>
>>>> java.lang.OutOfMemoryError: unable to create new native thread
>>>>at java.lang.Thread.start0(Native Method)
>>>>at java.lang.Thread.start(Thread.java:714)
>>>>at 
>>>> java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
>>>>at 
>>>> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1368)
>>>>at java.lang.UNIXProcess.initStreams(UNIXProcess.java:288)
>>>>at java.lang.UNIXProcess.lambda$new$2(UNIXProcess.java:258)
>>>>at java.security.AccessController.doPrivileged(Native Method)
>>>>at java.lang.UNIXProcess.(UNIXProcess.java:257)
>>>>at java.lang.ProcessImpl.start(ProcessImpl.java:134)
>>>>at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
>>>>at hudson.Proc$LocalProc.(Proc.java:249)
>>>> Also:   java.io.IOException: error=11, Resource temporarily unavailable
>>>>
>>>>
>>>>
>>>>
>>>> SEVERE: Unexpected error when retrieving changeset 
>>>> hudson.plugins.git.GitException: Error: git whatchanged --no-abbrev -M 
>>>> "--format=commit %H%ntree %T%nparent %P%nauthor %aN <%aE> % 
>>>> ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b" -n 1 
>>>> b2c871830a03ea5f2fd2b21245afb09d51d69686 in /home/build/jenkins/workspace/ 
>>>> project_user_work 
>>>>at 
>>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$6.execute(CliGitAPIImpl.java:1012)
>>>>  
>>>>
>>>>at 
>>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
>>>>  
>>>>
>>>>at 
>>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
>>>>  
>

Re: Memory issues with Jenkins

[Sverre Moe]

Could it be issue with the virtual memory in the jenkins server? Because 
Jenkins does consume a lot of virtual memory.

  PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ 
COMMAND
13565 jenkins   20   0 12.641g 0.011t  13552 S 0.000 56.62 625:25.18 
/usr/bin/java -XX:+UseG1GC -Xmx10g

It has amassed 12G of virtual memory. It is a problem with java and glibc
that can be remedied with
MALLOC_ARENA_MAX=1

I have tried adding ENVIRONMENT to /etc/systemd/system/jenkins.service, but 
it is not set before running jenkins.

https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en

https://stackoverflow.com/questions/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used/28935176#28935176


tirsdag 9. juli 2019 13.24.18 UTC+2 skrev Sverre Moe følgende:
>
>
> Since we don't use 32bit, the reason must be
> - the virtual memory of the OS has been fully depleted
>
> How can I check for this, and remedy it?
>
> fredag 5. juli 2019 03.17.38 UTC+2 skrev Jan Monterrubio følgende:
>
>> Correct me if I’m wrong but I don’t think increasing heap size will 
>> actually affect your ability to create more native threads. 
>>
>> See this for a possible explanation: 
>> https://plumbr.io/outofmemoryerror/unable-to-create-new-native-thread
>>
>> On Thu, Jul 4, 2019 at 16:03 Baptiste Mathus  wrote:
>>
>>> Did you enable GC logging to have a better understanding of the profile 
>>> of your memory consumption? If not, I would recommend you do it first and 
>>> analyze them.
>>> https://jenkins.io/blog/2016/11/21/gc-tuning/ explained this part (and 
>>> much more) quite well.
>>>
>>> Then, once you understand better when it crashes, possibly you'll want 
>>> to analyze a heap dump to see what is causing the problem.
>>>
>>> Cheers
>>>
>>>
>>> Le mar. 2 juil. 2019 à 15:30, Sverre Moe  a écrit :
>>>
>>>> Today it has been chaotic.
>>>> Several build agents disconnected
>>>>
>>>> Unexpected termination of the channel
>>>>
>>>> Many builds failed because of Memory error.
>>>>
>>>> I have tried restarting Jenkins several times today.
>>>>
>>>> Anyone have any suggestions?
>>>>
>>>> tirsdag 2. juli 2019 14.34.25 UTC+2 skrev Sverre Moe følgende:
>>>>>
>>>>> We have assigned 8GB of memory to our Jenkins instance.
>>>>> JAVA_OPTIONS=-Xmx8g
>>>>>
>>>>> Still we experience memory issues after a while running.
>>>>> java.lang.OutOfMemoryError: unable to create new native thread
>>>>>
>>>>> We have:
>>>>> aprox 40 connected build agents
>>>>> aprox 400 pipeline jobs
>>>>>
>>>>> We have a test Jenkins instance running with the same jobs, this one 
>>>>> connects to the same build agents (though on a different home directory).
>>>>>
>>>>> Lately we have been getting disconnected build agents, that we cannot 
>>>>> get up again without restarting Jenkins.
>>>>>
>>>>> Can we assign more memory to a build agent? Would it have any affect 
>>>>> on this issue?
>>>>>
>>>>> This we got from one of our latest Pipeline builds that failed on a 
>>>>> sh("find  -exec ***") step. It failed on that build agent that is now 
>>>>> disconnected.
>>>>>
>>>>>
>>>>> java.lang.OutOfMemoryError: unable to create new native thread
>>>>>   at java.lang.Thread.start0(Native Method)
>>>>>   at java.lang.Thread.start(Thread.java:714)
>>>>>   at 
>>>>> java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
>>>>>   at 
>>>>> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1368)
>>>>>   at java.lang.UNIXProcess.initStreams(UNIXProcess.java:288)
>>>>>   at java.lang.UNIXProcess.lambda$new$2(UNIXProcess.java:258)
>>>>>   at java.security.AccessController.doPrivileged(Native Method)
>>>>>   at java.lang.UNIXProcess.(UNIXProcess.java:257)
>>>>>   at java.lang.ProcessImpl.start(ProcessImpl.java:134)
>>>>>   at java.lang.ProcessBuilder.start(ProcessBui

Re: Jenkins Agents getting disconnected

[Sverre Moe]

Strange
If I configure the agent, save then try to reconnect it is able to create a 
connection and is back online.

tirsdag 9. juli 2019 13.20.55 UTC+2 skrev Sverre Moe følgende:
>
> On the build agents that gets disconnected there is plenty of available 
> disk space.
>
> When there are trying to connect, there are no remoting.jar java process 
> on the agent running.
>
> lørdag 6. juli 2019 22.59.31 UTC+2 skrev Karan Kaushik følgende:
>>
>> Hi
>>
>> We had been facing the same issue with Jenkins agent, one thing I 
>> remember doing was managing the space on the jenkins agent, the disconnect 
>> could happen due to no space remaining on agent machine.
>>
>

-- 
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/3dea1612-4bbe-49f0-98d4-696856501a90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Agents getting disconnected

[Sverre Moe]

I don't actually have to do anything, judt open Configure, Save, then 
Relaunch Agent.

fredag 12. juli 2019 13.30.05 UTC+2 skrev Sverre Moe følgende:
>
> Strange
> If I configure the agent, save then try to reconnect it is able to create 
> a connection and is back online.
>
> tirsdag 9. juli 2019 13.20.55 UTC+2 skrev Sverre Moe følgende:
>>
>> On the build agents that gets disconnected there is plenty of available 
>> disk space.
>>
>> When there are trying to connect, there are no remoting.jar java process 
>> on the agent running.
>>
>> lørdag 6. juli 2019 22.59.31 UTC+2 skrev Karan Kaushik følgende:
>>>
>>> Hi
>>>
>>> We had been facing the same issue with Jenkins agent, one thing I 
>>> remember doing was managing the space on the jenkins agent, the disconnect 
>>> could happen due to no space remaining on agent machine.
>>>
>>

-- 
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/e430054e-21a8-47ac-9bcc-bec37459f8ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Agents getting disconnected

[Sverre Moe]

Also when this happens, even after I have managed to relaunch the agent, no 
build can run on it. 
It stops on "Waiting for next available executor on ‘node-name’", even 
though it is online.
the previous build I stopped is still on the executor. The only solution is 
to restart Jenkins.

fredag 12. juli 2019 14.23.24 UTC+2 skrev Sverre Moe følgende:
>
> I don't actually have to do anything, judt open Configure, Save, then 
> Relaunch Agent.
>
> fredag 12. juli 2019 13.30.05 UTC+2 skrev Sverre Moe følgende:
>>
>> Strange
>> If I configure the agent, save then try to reconnect it is able to create 
>> a connection and is back online.
>>
>> tirsdag 9. juli 2019 13.20.55 UTC+2 skrev Sverre Moe følgende:
>>>
>>> On the build agents that gets disconnected there is plenty of available 
>>> disk space.
>>>
>>> When there are trying to connect, there are no remoting.jar java process 
>>> on the agent running.
>>>
>>> lørdag 6. juli 2019 22.59.31 UTC+2 skrev Karan Kaushik følgende:
>>>>
>>>> Hi
>>>>
>>>> We had been facing the same issue with Jenkins agent, one thing I 
>>>> remember doing was managing the space on the jenkins agent, the disconnect 
>>>> could happen due to no space remaining on agent machine.
>>>>
>>>

-- 
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/7707010a-2d74-4ea7-9e21-64f5c69604d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Memory issues with Jenkins

[Sverre Moe]

jenkins@meoscorebs12:~> ulimit -a 
core file size  (blocks, -c) unlimited 
data seg size   (kbytes, -d) unlimited 
scheduling priority (-e) 0 
file size   (blocks, -f) unlimited 
pending signals (-i) 80229 
max locked memory   (kbytes, -l) 64 
max memory size (kbytes, -m) unlimited 
open files  (-n) 1024 
pipe size(512 bytes, -p) 8 
POSIX message queues (bytes, -q) 819200 
real-time priority  (-r) 0 
stack size  (kbytes, -s) 8192 
cpu time   (seconds, -t) unlimited 
max user processes  (-u) 80229 
virtual memory  (kbytes, -v) unlimited 
file locks  (-x) unlimited


I have check the number of processes, with "ps aux", but not the number of 
threads.
Right now, (Jenkins was restarted 2 day ago and few builds have run), there 
are 264 threads for Jenkins currently.
Is there any way I can find out what each thread is for?

lørdag 13. juli 2019 13.02.15 UTC+2 skrev Ivan Fernandez Calvo følgende:
>
> Hi,
>
> When the issue happens, Did you check the number of threads that Jenkins 
> has open? How many file descriptors can your process open (run ulimit -a 
> with the user jenkins)? here you have a good KB about memory and user 
> limit on Jenkins Prepare Jenkins for Support 
> 
>

-- 
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/363d9039-e391-4682-97bc-d332039bc83f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Agents getting disconnected

[Sverre Moe]

I suspected it might be related, but was not sure. 

The odd thing this just started being a problem a week ago. Nothing as far 
as I can see has changed on the Jenkins server.

lørdag 13. juli 2019 13.04.44 UTC+2 skrev Ivan Fernandez Calvo følgende:
>
> I saw that you have another question related with OOM errors in Jenkins if 
> it is the same instance , this is your real issue with the agents, until 
> you do not have a stable Jenkins instance the agent disconnection will be a 
> side effect.
>>
>>

-- 
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/661096a3-4689-4162-8d75-e644090d568a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Memory issues with Jenkins

[Sverre Moe]

I checked out that link

Tried the ulimit settings
https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support#bulimitsettingsjustforlinuxos

Will try the additional JVM flags suggested in
https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support#ajavaparameters

søndag 14. juli 2019 13.29.22 UTC+2 skrev Sverre Moe følgende:
>
> jenkins@meoscorebs12:~> ulimit -a 
> core file size  (blocks, -c) unlimited 
> data seg size   (kbytes, -d) unlimited 
> scheduling priority (-e) 0 
> file size   (blocks, -f) unlimited 
> pending signals (-i) 80229 
> max locked memory   (kbytes, -l) 64 
> max memory size (kbytes, -m) unlimited 
> open files  (-n) 1024 
> pipe size(512 bytes, -p) 8 
> POSIX message queues (bytes, -q) 819200 
> real-time priority  (-r) 0 
> stack size  (kbytes, -s) 8192 
> cpu time   (seconds, -t) unlimited 
> max user processes  (-u) 80229 
> virtual memory  (kbytes, -v) unlimited 
> file locks  (-x) unlimited
>
>
> I have check the number of processes, with "ps aux", but not the number of 
> threads.
> Right now, (Jenkins was restarted 2 day ago and few builds have run), 
> there are 264 threads for Jenkins currently.
> Is there any way I can find out what each thread is for?
>
> lørdag 13. juli 2019 13.02.15 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>
>> Hi,
>>
>> When the issue happens, Did you check the number of threads that Jenkins 
>> has open? How many file descriptors can your process open (run ulimit -a 
>> with the user jenkins)? here you have a good KB about memory and user 
>> limit on Jenkins Prepare Jenkins for Support 
>> <https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support>
>>
>

-- 
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/ef859447-1b6c-4fe0-b386-c804692c8258%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Agents getting disconnected

[Sverre Moe]

We have had to blissfull days of stable Jenkins. Today two nodes are 
disconnected and they will not come back online.

What is strange is it is the same two-three nodes every time.
Running disconnect on them through the URL 
http://jenkins.example.com/jenkins/computer/NODE_NAME/disconnect, does not 
work.
I have to enter configuration, Save, then relaunch to get them up running.

I tried setting the ulimit values as suggested in
https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support#bulimitsettingsjustforlinuxos

I have also added additional JVM options as suggested in
https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support#ajavaparameters
https://go.cloudbees.com/docs/solutions/jvm-troubleshooting/

The number of threads of Jenkins server is currently 265. Yesterday when 
all was fine this was up to 300.


Maybe ralted or unrelated:
When this happens we have some builds on other nodes that stops working. 
They are aborted, but are still showing as running. The only thing that 
works is deleting the agent and creating it again, that or restarting 
Jenkins.


søndag 14. juli 2019 13.31.51 UTC+2 skrev Sverre Moe følgende:
>
> I suspected it might be related, but was not sure. 
>
> The odd thing this just started being a problem a week ago. Nothing as far 
> as I can see has changed on the Jenkins server.
>
> lørdag 13. juli 2019 13.04.44 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>
>> I saw that you have another question related with OOM errors in Jenkins 
>> if it is the same instance , this is your real issue with the agents, until 
>> you do not have a stable Jenkins instance the agent disconnection will be a 
>> side effect.
>>>
>>>

-- 
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/f64ce739-9706-4fc3-8c39-02b93cd45253%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Agents getting disconnected

[Sverre Moe]

It seems to be the monitoring that gets the agents disconnected.

Got this in my log file this last time they got disconnectd.

Jul 17, 2019 11:58:22 AM 
hudson.init.impl.InstallUncaughtExceptionHandler$DefaultUncaughtExceptionHandler
 
uncaughtExc 
eption 
SEVERE: A thread (Timer-3450/103166) died unexpectedly due to an uncaught 
exception, this may leave your Jenkins in a 
bad way and is usually indicative of a bug in the code. 
java.lang.OutOfMemoryError: unable to create new native thread 
   at java.lang.Thread.start0(Native Method) 
   at java.lang.Thread.start(Thread.java:717) 
   at java.util.Timer.(Timer.java:160) 
   at java.util.Timer.(Timer.java:132) 
   at 
org.jenkinsci.plugins.ssegateway.sse.EventDispatcher.scheduleRetryQueueProcessing(EventDispatcher.java:296
 

) 
   at 
org.jenkinsci.plugins.ssegateway.sse.EventDispatcher.processRetries(EventDispatcher.java:437)
 

   at 
org.jenkinsci.plugins.ssegateway.sse.EventDispatcher$1.run(EventDispatcher.java:299)
 

   at java.util.TimerThread.mainLoop(Timer.java:555) 
   at java.util.TimerThread.run(Timer.java:505)

Jul 17, 2019 11:58:31 AM 
hudson.init.impl.InstallUncaughtExceptionHandler$DefaultUncaughtExceptionHandler
 
uncaughtExc 
eption 
SEVERE: A thread (Thread-30062/98187) died unexpectedly due to an uncaught 
exception, this may leave your Jenkins in  
a bad way and is usually indicative of a bug in the code. 
java.lang.OutOfMemoryError: unable to create new native thread 
   at java.lang.Thread.start0(Native Method) 
   at java.lang.Thread.start(Thread.java:717) 
   at 
com.trilead.ssh2.transport.TransportManager.sendAsynchronousMessage(TransportManager.java:649)
 

   at 
com.trilead.ssh2.channel.ChannelManager.msgChannelRequest(ChannelManager.java:1213)
 

   at 
com.trilead.ssh2.channel.ChannelManager.handleMessage(ChannelManager.java:1466) 

   at 
com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:809)
 

   at 
com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:502) 

   at java.lang.Thread.run(Thread.java:748)


Now I have gotten catastrophic failure. I cannot relaunch any agents any 
more.

[07/17/19 12:04:10] [SSH] Opening SSH connection to 
jbssles120x64r12.spacetec.no:22.
ERROR: Unexpected error in launching a agent. This is probably a bug in Jenkins.
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:717)
at 
com.trilead.ssh2.transport.TransportManager.initialize(TransportManager.java:545)
at com.trilead.ssh2.Connection.connect(Connection.java:774)
at 
hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:817)
at hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:419)
at hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:406)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
[07/17/19 12:04:10] Launch failed - cleaning up connection
[07/17/19 12:04:10] [SSH] Connection closed.


My Jenkins server has over 500 threads open
Threads: 506 total,   0 running, 506 sleeping,   0 stopped,   0 zombie


onsdag 17. juli 2019 10.24.12 UTC+2 skrev Sverre Moe følgende:
>
> We have had to blissfull days of stable Jenkins. Today two nodes are 
> disconnected and they will not come back online.
>
> What is strange is it is the same two-three nodes every time.
> Running disconnect on them through the URL 
> http://jenkins.example.com/jenkins/computer/NODE_NAME/disconnect, does 
> not work.
> I have to enter configuration, Save, then relaunch to get them up running.
>
> I tried setting the ulimit values as suggested in
>
> https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support#bulimitsettingsjustforlinuxos
>
> I have also added additional JVM options as suggested in
>
> https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support#ajavaparameters
> https://go.cloudbees.com/docs/solutions/jvm-troubleshooting/
>
> The number of threads of Jenkins server is currently 265. Yesterday when 
> all was fine this was up to 300.
>
>
> Maybe ralted or unrelated:
> When this happens we have some builds on other nodes that stops working. 
> They are aborted, but are still showing as running. The only thing that 
> works is deleting the agent and creating it again, that or restarting 
> Jenkins.
>
>
> søndag 14. juli 2019 13.31.51 UTC+2 skrev Sverre Moe følgende:
>>
>> I suspected it might be related, but was not sure. 
>>
>> The odd 

Re: Jenkins Agents getting disconnected

[Sverre Moe]

I ran jstack on Jenkins, and many of the threads had state BLOCKED.
However after a restart most of the threads are BLOCKED. Not sure if it is 
an issue here.

After a restart Jenkins starts with aprox 200 threads open.
When I got problem with disconnected agents, the thread count reached 500.

onsdag 17. juli 2019 12.40.14 UTC+2 skrev Sverre Moe følgende:
>
> It seems to be the monitoring that gets the agents disconnected.
>
> Got this in my log file this last time they got disconnectd.
>
> Jul 17, 2019 11:58:22 AM 
> hudson.init.impl.InstallUncaughtExceptionHandler$DefaultUncaughtExceptionHandler
>  
> uncaughtExc 
> eption 
> SEVERE: A thread (Timer-3450/103166) died unexpectedly due to an uncaught 
> exception, this may leave your Jenkins in a 
> bad way and is usually indicative of a bug in the code. 
> java.lang.OutOfMemoryError: unable to create new native thread 
>at java.lang.Thread.start0(Native Method) 
>at java.lang.Thread.start(Thread.java:717) 
>at java.util.Timer.(Timer.java:160) 
>at java.util.Timer.(Timer.java:132) 
>at 
> org.jenkinsci.plugins.ssegateway.sse.EventDispatcher.scheduleRetryQueueProcessing(EventDispatcher.java:296
>  
>
> ) 
>at 
> org.jenkinsci.plugins.ssegateway.sse.EventDispatcher.processRetries(EventDispatcher.java:437)
>  
>
>at 
> org.jenkinsci.plugins.ssegateway.sse.EventDispatcher$1.run(EventDispatcher.java:299)
>  
>
>at java.util.TimerThread.mainLoop(Timer.java:555) 
>at java.util.TimerThread.run(Timer.java:505)
>
> Jul 17, 2019 11:58:31 AM 
> hudson.init.impl.InstallUncaughtExceptionHandler$DefaultUncaughtExceptionHandler
>  
> uncaughtExc 
> eption 
> SEVERE: A thread (Thread-30062/98187) died unexpectedly due to an uncaught 
> exception, this may leave your Jenkins in  
> a bad way and is usually indicative of a bug in the code. 
> java.lang.OutOfMemoryError: unable to create new native thread 
>at java.lang.Thread.start0(Native Method) 
>at java.lang.Thread.start(Thread.java:717) 
>at 
> com.trilead.ssh2.transport.TransportManager.sendAsynchronousMessage(TransportManager.java:649)
>  
>
>at 
> com.trilead.ssh2.channel.ChannelManager.msgChannelRequest(ChannelManager.java:1213)
>  
>
>at 
> com.trilead.ssh2.channel.ChannelManager.handleMessage(ChannelManager.java:1466)
>  
>
>at 
> com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:809)
>  
>
>at 
> com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:502) 
>
>at java.lang.Thread.run(Thread.java:748)
>
>
> Now I have gotten catastrophic failure. I cannot relaunch any agents any 
> more.
>
> [07/17/19 12:04:10] [SSH] Opening SSH connection to 
> jbssles120x64r12.spacetec.no:22.
> ERROR: Unexpected error in launching a agent. This is probably a bug in 
> Jenkins.
> java.lang.OutOfMemoryError: unable to create new native thread
>   at java.lang.Thread.start0(Native Method)
>   at java.lang.Thread.start(Thread.java:717)
>   at 
> com.trilead.ssh2.transport.TransportManager.initialize(TransportManager.java:545)
>   at com.trilead.ssh2.Connection.connect(Connection.java:774)
>   at 
> hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:817)
>   at hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:419)
>   at hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:406)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> [07/17/19 12:04:10] Launch failed - cleaning up connection
> [07/17/19 12:04:10] [SSH] Connection closed.
>
>
> My Jenkins server has over 500 threads open
> Threads: 506 total,   0 running, 506 sleeping,   0 stopped,   0 zombie
>
>
> onsdag 17. juli 2019 10.24.12 UTC+2 skrev Sverre Moe følgende:
>>
>> We have had to blissfull days of stable Jenkins. Today two nodes are 
>> disconnected and they will not come back online.
>>
>> What is strange is it is the same two-three nodes every time.
>> Running disconnect on them through the URL 
>> http://jenkins.example.com/jenkins/computer/NODE_NAME/disconnect, does 
>> not work.
>> I have to enter configuration, Save, then relaunch to get them up running.
>>
>> I tried setting the ulimit values as suggested in
>>
>> https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support#buli

Re: Jenkins Agents getting disconnected

[Sverre Moe]

I cannot see any specific plugins in the stacktrace.
There are several duplicate threads. Here are some of them.
Most common denominator seems to be about SSH.

Thread 29360: (state = BLOCKED) 
- java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
imprecise) 
- java.lang.Object.wait() @bci=2, line=502 (Compiled frame) 
- java.util.TimerThread.mainLoop() @bci=28, line=526 (Compiled frame) 
- java.util.TimerThread.run() @bci=1, line=505 (Compiled frame)

Thread 29339: (state = BLOCKED) 
- hudson.plugins.sshslaves.SSHLauncher.launch(hudson.slaves.SlaveComputer, 
hudson.model.TaskListener) @bci=25, line=401 (Compiled frame) 
- hudson.slaves.SlaveComputer$1.call() @bci=88, line=294 (Compiled frame) 
- jenkins.util.ContextResettingExecutorService$2.call() @bci=18, line=46 
(Compiled frame) 
- jenkins.security.ImpersonatingExecutorService$2.call() @bci=17, line=71 
(Compiled frame) 
- java.util.concurrent.FutureTask.run() @bci=42, line=266 (Compiled frame) 
- 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
 
@bci=95, line=1149 (Compiled frame) 
- java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=624 
(Compiled frame) 
- java.lang.Thread.run() @bci=11, line=748 (Compiled frame) 

Thread 29122: (state = BLOCKED) 
- java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be 
imprecise) 
- java.lang.Object.wait() @bci=2, line=502 (Compiled frame) 
- 
com.trilead.ssh2.channel.ChannelManager.waitUntilChannelOpen(com.trilead.ssh2.channel.Channel)
 
@bci=13, line=110 (Compiled frame) 
- com.trilead.ssh2.channel.ChannelManager.openSessionChannel() @bci=109, 
line=574 (Compiled frame) 
- com.trilead.ssh2.Session.(com.trilead.ssh2.channel.ChannelManager, 
java.security.SecureRandom) @bci=36, line=42 (Compiled frame) 
- com.trilead.ssh2.Connection.openSession() @bci=46, line=1145 (Compiled 
frame) 
- com.trilead.ssh2.Connection.exec(java.lang.String, java.io.OutputStream) 
@bci=1, line=1566 (Compiled frame) 
- hudson.plugins.sshslaves.SSHLauncher$3.run() @bci=79, line=969 (Compiled 
frame) 
- jenkins.util.ContextResettingExecutorService$1.run() @bci=18, line=28 
(Compiled frame) 
- jenkins.security.ImpersonatingExecutorService$1.run() @bci=17, line=59 
(Compiled frame) 
- java.util.concurrent.Executors$RunnableAdapter.call() @bci=4, line=511 
(Compiled frame) 
- java.util.concurrent.FutureTask.run() @bci=42, line=266 (Compiled frame) 
- 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
 
@bci=95, line=1149 (Compiled frame) 
- java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=624 
(Compiled frame) 
- java.lang.Thread.run() @bci=11, line=748 (Compiled frame)

Thread 28586: (state = BLOCKED) 
- sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information 
may be imprecise) 
- java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long) 
@bci=20, line=215 (Compiled frame) 
- 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(long,
 
java.util.concurrent.TimeUnit) @bci=97, line=2163 (Compiled frame) 
- 
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.reservedWait()
 
@bci=97, line=292 (Compiled frame) 
- org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run() 
@bci=188, line=357 (Compiled frame) 
- org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(java.lang.Runnable) 
@bci=1, line=765 (Compiled frame) 
- org.eclipse.jetty.util.thread.QueuedThreadPool$2.run() @bci=104, line=683 
(Compiled frame) 
- java.lang.Thread.run() @bci=11, line=748 (Compiled frame) 

Thread 28324: (state = BLOCKED) 
- java.lang.Thread.sleep(long) @bci=0 (Compiled frame; information may be 
imprecise) 
- hudson.remoting.PingThread.run() @bci=38, line=95 (Compiled frame)

Thread 27552: (state = BLOCKED) 
- com.trilead.ssh2.Connection.close() @bci=0, line=573 (Compiled frame) 
- 
hudson.plugins.sshslaves.SSHLauncher.cleanupConnection(hudson.model.TaskListener)
 
@bci=11, line=511 (Compiled frame) 
- 
hudson.plugins.sshslaves.SSHLauncher.tearDownConnectionImpl(hudson.slaves.SlaveComputer,
 
hudson.model.TaskListener) @bci=345, line=1006 (Compiled frame) 
- 
hudson.plugins.sshslaves.SSHLauncher.tearDownConnection(hudson.slaves.SlaveComputer,
 
hudson.model.TaskListener) @bci=10, line=930 (Compiled frame) 
- 
hudson.plugins.sshslaves.SSHLauncher.afterDisconnect(hudson.slaves.SlaveComputer,
 
hudson.model.TaskListener) @bci=50, line=925 (Compiled frame) 
- hudson.slaves.SlaveComputer$3.run() @bci=46, line=738 (Compiled frame) 
- jenkins.util.ContextResettingExecutorService$1.run() @bci=18, line=28 
(Compiled frame) 
- jenkins.security.ImpersonatingExecutorService$1.run() @bci=17, line=59 
(Compiled frame) 
- java.util.concurrent.Executors$RunnableAdapter.call() @bci=4, line=511 
(Compiled frame) 
- java.util.concurrent.FutureTask.run() @bci=42, line=266 (Compiled frame) 
- 
java.util.concurrent.ThreadPoolExecutor.

Re: Jenkins Agents getting disconnected

[Sverre Moe]

There is no such reference in my jstack output.
The output says no deadlock detected.
I will try that site for analyzing the jstack.

Even a normal running Jenkins has many BLOCKED threads. If that is normal I 
don't know.

We have a test Jenkins instance running on Java 11. That one does not have 
any BLOCKED threads.
Our production Jenkins is running Java 8u181.

torsdag 18. juli 2019 11.04.16 UTC+2 skrev Ivan Fernandez Calvo følgende:
>
> In that dump I can not see which thread is blocking the others, the jstack 
> output has a reference on each thread that said what thread is the blocker 
> on each thread (- locked <0x> a java.lang.Object), you can try to 
> analyze those thread dump with https://fastthread.io/index.jsp or other 
> online tools to see if you see something relevant, it looks like there is a 
> deadlock.
>
> https://dzone.com/articles/how-to-read-a-thread-dump
>

-- 
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/d1a855fe-34fb-4e88-973f-8c2b8fa0ab22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline: Expected call wound up catching different method

[Sverre Moe]

I got a problem with my Pipeline which has worked fine up until recently.
I don't quite understand what the problem is:

expected to call Build.checkUpstream but wound up catching 
releaseUtility.getReleaseBranch; see: 
https://jenkins.io/redirect/pipeline-cps-method-mismatches/
expected to call Build.checkDownstream but wound up catching 
releaseUtility.getReleaseBranch; see: 
https://jenkins.io/redirect/pipeline-cps-method-mismatches/


src/no/company/ci/Build.groovy

@NonCPS void checkUpstream(upstreamDependencies, projectName, 
buildEnvironment, releasePackages)
@NonCPS void checkDownstream(downstreamDependencies, projectName, 
buildEnvironment, releasePackages)


vars/releaseUtility.groovy

def getReleaseBranch(projectName, buildEnvironment, releasePackages)



The checkUpstream goes through all upstream projects, find out which has failed 
and trigger a build on them

The checkDownstream does the same for upstream projects.


Both these methods makes a call to releaseUtility.getReleaseBranch.


Is this the reason? "it is impossible for non-CPS-transformed code to call 
CPS-transformed code"

I guess then getReleaseBranch needs to also be annotated with NonCPS.


Maybe I no longer need NonCPS on checkUpstream and checkDownstream (ref 
JENKINS-26481  mentioned in 
the URL above).

These methods do not call node or sh step (just build and println). They do 
access the Jenkins instance to jenkinsInstance.getItemByFullName and 
getting all the jobs for 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/15494592-78a8-4e87-b687-be4eac9d7891%40googlegroups.com.

Re: Jenkins Agents getting disconnected

[Sverre Moe]

I was unable to determine something from the stack output
Here is the 
result: 
https://fastthread.io/my-thread-report.jsp?p=c2hhcmVkLzIwMTkvMDcvMjkvLS1qc3RhY2sudHh0LS05LTE2LTI3

torsdag 18. juli 2019 11.28.06 UTC+2 skrev Sverre Moe følgende:
>
> There is no such reference in my jstack output.
> The output says no deadlock detected.
> I will try that site for analyzing the jstack.
>
> Even a normal running Jenkins has many BLOCKED threads. If that is normal 
> I don't know.
>
> We have a test Jenkins instance running on Java 11. That one does not have 
> any BLOCKED threads.
> Our production Jenkins is running Java 8u181.
>
> torsdag 18. juli 2019 11.04.16 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>
>> In that dump I can not see which thread is blocking the others, the 
>> jstack output has a reference on each thread that said what thread is the 
>> blocker on each thread (- locked <0x> a java.lang.Object), you 
>> can try to analyze those thread dump with https://fastthread.io/index.jsp or 
>> other online tools to see if you see something relevant, it looks like 
>> there is a deadlock.
>>
>> https://dzone.com/articles/how-to-read-a-thread-dump
>>
>

-- 
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/9ae17af0-1ed6-4365-8050-aef2b025d6cf%40googlegroups.com.

Re: Memory issues with Jenkins

[Sverre Moe]

I have analyzed the GC log

https://www.gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMTkvMDcvMjgvLS1nYy0yMDE5LTA3LTI2XzE3LTMxLTIyLmxvZy4wLmN1cnJlbnQtLTE1LTI0LTQy&channel=WEB

This may be related to another issue I am having when build agents are 
getting disconnected.
https://groups.google.com/forum/#!topic/jenkinsci-users/UDyaH-kfqqA

I also have an jstack output analyzed:
https://fastthread.io/my-thread-report.jsp?p=c2hhcmVkLzIwMTkvMDcvMjkvLS1qc3RhY2sudHh0LS05LTE2LTI3

søndag 14. juli 2019 13.48.57 UTC+2 skrev Sverre Moe følgende:
>
> I checked out that link
>
> Tried the ulimit settings
>
> https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support#bulimitsettingsjustforlinuxos
>
> Will try the additional JVM flags suggested in
>
> https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support#ajavaparameters
>
> søndag 14. juli 2019 13.29.22 UTC+2 skrev Sverre Moe følgende:
>>
>> jenkins@meoscorebs12:~> ulimit -a 
>> core file size  (blocks, -c) unlimited 
>> data seg size   (kbytes, -d) unlimited 
>> scheduling priority (-e) 0 
>> file size   (blocks, -f) unlimited 
>> pending signals (-i) 80229 
>> max locked memory   (kbytes, -l) 64 
>> max memory size (kbytes, -m) unlimited 
>> open files  (-n) 1024 
>> pipe size(512 bytes, -p) 8 
>> POSIX message queues (bytes, -q) 819200 
>> real-time priority  (-r) 0 
>> stack size  (kbytes, -s) 8192 
>> cpu time   (seconds, -t) unlimited 
>> max user processes  (-u) 80229 
>> virtual memory  (kbytes, -v) unlimited 
>> file locks  (-x) unlimited
>>
>>
>> I have check the number of processes, with "ps aux", but not the number 
>> of threads.
>> Right now, (Jenkins was restarted 2 day ago and few builds have run), 
>> there are 264 threads for Jenkins currently.
>> Is there any way I can find out what each thread is for?
>>
>> lørdag 13. juli 2019 13.02.15 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>>
>>> Hi,
>>>
>>> When the issue happens, Did you check the number of threads that Jenkins 
>>> has open? How many file descriptors can your process open (run ulimit 
>>> -a with the user jenkins)? here you have a good KB about memory and 
>>> user limit on Jenkins Prepare Jenkins for Support 
>>> <https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support>
>>>
>>

-- 
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/1465add4-191b-46c3-bd08-31816f0cc82b%40googlegroups.com.

Re: Jenkins Agents getting disconnected

[Sverre Moe]

Yes, we are using NFS for JENKINS_HOME.

mandag 29. juli 2019 15.41.00 UTC+2 skrev Ivan Fernandez Calvo følgende:
>
> you have 83 threads in state:IN_NATIVE, probably stuck in IO operations, 
> those 83 threads are blocking the other 382 threads, if you use an NFS or 
> similar device for you Jenkins HOME this is probably your bottleneck, if 
> not check the IO stats on the OS to see where you have the bottleneck.
>
> El lunes, 29 de julio de 2019, 11:20:50 (UTC+2), Sverre Moe escribió:
>>
>> I was unable to determine something from the stack output
>> Here is the result: 
>> https://fastthread.io/my-thread-report.jsp?p=c2hhcmVkLzIwMTkvMDcvMjkvLS1qc3RhY2sudHh0LS05LTE2LTI3
>>
>> torsdag 18. juli 2019 11.28.06 UTC+2 skrev Sverre Moe følgende:
>>>
>>> There is no such reference in my jstack output.
>>> The output says no deadlock detected.
>>> I will try that site for analyzing the jstack.
>>>
>>> Even a normal running Jenkins has many BLOCKED threads. If that is 
>>> normal I don't know.
>>>
>>> We have a test Jenkins instance running on Java 11. That one does not 
>>> have any BLOCKED threads.
>>> Our production Jenkins is running Java 8u181.
>>>
>>> torsdag 18. juli 2019 11.04.16 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>>>
>>>> In that dump I can not see which thread is blocking the others, the 
>>>> jstack output has a reference on each thread that said what thread is the 
>>>> blocker on each thread (- locked <0x> a java.lang.Object), you 
>>>> can try to analyze those thread dump with 
>>>> https://fastthread.io/index.jsp or other online tools to see if you 
>>>> see something relevant, it looks like there is a deadlock.
>>>>
>>>> https://dzone.com/articles/how-to-read-a-thread-dump
>>>>
>>>

-- 
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/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com.

Re: Memory issues with Jenkins

[Sverre Moe]

Have not yet resolved the issue. Not found a solution, nor what the cause 
actually is.

lørdag 3. august 2019 13.04.10 UTC+2 skrev guerkan demirci følgende:
>
> Hi Sverre Moe,
>
> could you resolve the issue?
> I have the same problem with Jenkins.
>
> Best
>
>
> Am Montag, 29. Juli 2019 11:30:58 UTC+2 schrieb Sverre Moe:
>>
>> I have analyzed the GC log
>>
>>
>> https://www.gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMTkvMDcvMjgvLS1nYy0yMDE5LTA3LTI2XzE3LTMxLTIyLmxvZy4wLmN1cnJlbnQtLTE1LTI0LTQy&channel=WEB
>>
>> This may be related to another issue I am having when build agents are 
>> getting disconnected.
>> https://groups.google.com/forum/#!topic/jenkinsci-users/UDyaH-kfqqA
>>
>> I also have an jstack output analyzed:
>>
>> https://fastthread.io/my-thread-report.jsp?p=c2hhcmVkLzIwMTkvMDcvMjkvLS1qc3RhY2sudHh0LS05LTE2LTI3
>>
>> søndag 14. juli 2019 13.48.57 UTC+2 skrev Sverre Moe følgende:
>>>
>>> I checked out that link
>>>
>>> Tried the ulimit settings
>>>
>>> https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support#bulimitsettingsjustforlinuxos
>>>
>>> Will try the additional JVM flags suggested in
>>>
>>> https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support#ajavaparameters
>>>
>>> søndag 14. juli 2019 13.29.22 UTC+2 skrev Sverre Moe følgende:
>>>>
>>>> jenkins@meoscorebs12:~> ulimit -a 
>>>> core file size  (blocks, -c) unlimited 
>>>> data seg size   (kbytes, -d) unlimited 
>>>> scheduling priority (-e) 0 
>>>> file size   (blocks, -f) unlimited 
>>>> pending signals (-i) 80229 
>>>> max locked memory   (kbytes, -l) 64 
>>>> max memory size (kbytes, -m) unlimited 
>>>> open files  (-n) 1024 
>>>> pipe size(512 bytes, -p) 8 
>>>> POSIX message queues (bytes, -q) 819200 
>>>> real-time priority  (-r) 0 
>>>> stack size  (kbytes, -s) 8192 
>>>> cpu time   (seconds, -t) unlimited 
>>>> max user processes  (-u) 80229 
>>>> virtual memory  (kbytes, -v) unlimited 
>>>> file locks  (-x) unlimited
>>>>
>>>>
>>>> I have check the number of processes, with "ps aux", but not the number 
>>>> of threads.
>>>> Right now, (Jenkins was restarted 2 day ago and few builds have run), 
>>>> there are 264 threads for Jenkins currently.
>>>> Is there any way I can find out what each thread is for?
>>>>
>>>> lørdag 13. juli 2019 13.02.15 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>>>>
>>>>> Hi,
>>>>>
>>>>> When the issue happens, Did you check the number of threads that 
>>>>> Jenkins has open? How many file descriptors can your process open (run 
>>>>> ulimit 
>>>>> -a with the user jenkins)? here you have a good KB about memory and 
>>>>> user limit on Jenkins Prepare Jenkins for Support 
>>>>> <https://support.cloudbees.com/hc/en-us/articles/222446987-Prepare-Jenkins-for-Support>
>>>>>
>>>>

-- 
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/6b4b772c-3f8c-4d1f-aafd-94e4eea7298d%40googlegroups.com.

Re: Jenkins Agents getting disconnected

[Sverre Moe]

I was mistaken. We did not use NFS.
The disk for JENKINS_HOME (Jenkins running on VM), is a LVM disk.

mandag 29. juli 2019 18.15.20 UTC+2 skrev Ivan Fernandez Calvo følgende:
>
> check the Cloudbees links, I've helped to write those KB when I was on 
> CloudBees :), I'm pretty sure that the NFS is your pain and the root cause 
> of all your problems if you can rid of it better.
>
> El lunes, 29 de julio de 2019, 18:03:59 (UTC+2), slide escribió:
>>
>> CloudBees (not my employer) has some resources on using NFS (generally 
>> the recommendation is to NOT use NFS for JENKINS_HOME). 
>>
>>
>> https://support.cloudbees.com/hc/en-us/articles/115000486312-CJP-Performance-Best-Practices-for-Linux#nfs
>>  
>> and
>> https://support.cloudbees.com/hc/en-us/articles/217479948-NFS-Guide 
>>
>> On Mon, Jul 29, 2019 at 8:51 AM Sverre Moe  wrote:
>>
>>> Yes, we are using NFS for JENKINS_HOME.
>>>
>>> mandag 29. juli 2019 15.41.00 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>>>
>>>> you have 83 threads in state:IN_NATIVE, probably stuck in IO 
>>>> operations, those 83 threads are blocking the other 382 threads, if you 
>>>> use 
>>>> an NFS or similar device for you Jenkins HOME this is probably your 
>>>> bottleneck, if not check the IO stats on the OS to see where you have the 
>>>> bottleneck.
>>>>
>>>> El lunes, 29 de julio de 2019, 11:20:50 (UTC+2), Sverre Moe escribió:
>>>>>
>>>>> I was unable to determine something from the stack output
>>>>> Here is the result: 
>>>>> https://fastthread.io/my-thread-report.jsp?p=c2hhcmVkLzIwMTkvMDcvMjkvLS1qc3RhY2sudHh0LS05LTE2LTI3
>>>>>
>>>>> torsdag 18. juli 2019 11.28.06 UTC+2 skrev Sverre Moe følgende:
>>>>>>
>>>>>> There is no such reference in my jstack output.
>>>>>> The output says no deadlock detected.
>>>>>> I will try that site for analyzing the jstack.
>>>>>>
>>>>>> Even a normal running Jenkins has many BLOCKED threads. If that is 
>>>>>> normal I don't know.
>>>>>>
>>>>>> We have a test Jenkins instance running on Java 11. That one does not 
>>>>>> have any BLOCKED threads.
>>>>>> Our production Jenkins is running Java 8u181.
>>>>>>
>>>>>> torsdag 18. juli 2019 11.04.16 UTC+2 skrev Ivan Fernandez Calvo 
>>>>>> følgende:
>>>>>>>
>>>>>>> In that dump I can not see which thread is blocking the others, the 
>>>>>>> jstack output has a reference on each thread that said what thread is 
>>>>>>> the 
>>>>>>> blocker on each thread (- locked <0x> a java.lang.Object), 
>>>>>>> you can try to analyze those thread dump with 
>>>>>>> https://fastthread.io/index.jsp or other online tools to see if you 
>>>>>>> see something relevant, it looks like there is a deadlock.
>>>>>>>
>>>>>>> https://dzone.com/articles/how-to-read-a-thread-dump
>>>>>>>
>>>>>> -- 
>>> 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/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> -- 
>> Website: http://earl-of-code.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/da7baa40-bdac-490b-bad6-067aba4591b4%40googlegroups.com.

Re: Jenkins Agents getting disconnected

[Sverre Moe]

We do have one NFS, for copying build artifacts to RPM repository.

tirsdag 6. august 2019 09.08.48 UTC+2 skrev Sverre Moe følgende:
>
> I was mistaken. We did not use NFS.
> The disk for JENKINS_HOME (Jenkins running on VM), is a LVM disk.
>
> mandag 29. juli 2019 18.15.20 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>
>> check the Cloudbees links, I've helped to write those KB when I was on 
>> CloudBees :), I'm pretty sure that the NFS is your pain and the root cause 
>> of all your problems if you can rid of it better.
>>
>> El lunes, 29 de julio de 2019, 18:03:59 (UTC+2), slide escribió:
>>>
>>> CloudBees (not my employer) has some resources on using NFS (generally 
>>> the recommendation is to NOT use NFS for JENKINS_HOME). 
>>>
>>>
>>> https://support.cloudbees.com/hc/en-us/articles/115000486312-CJP-Performance-Best-Practices-for-Linux#nfs
>>>  
>>> and
>>> https://support.cloudbees.com/hc/en-us/articles/217479948-NFS-Guide 
>>>
>>> On Mon, Jul 29, 2019 at 8:51 AM Sverre Moe  wrote:
>>>
>>>> Yes, we are using NFS for JENKINS_HOME.
>>>>
>>>> mandag 29. juli 2019 15.41.00 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>>>>
>>>>> you have 83 threads in state:IN_NATIVE, probably stuck in IO 
>>>>> operations, those 83 threads are blocking the other 382 threads, if you 
>>>>> use 
>>>>> an NFS or similar device for you Jenkins HOME this is probably your 
>>>>> bottleneck, if not check the IO stats on the OS to see where you have the 
>>>>> bottleneck.
>>>>>
>>>>> El lunes, 29 de julio de 2019, 11:20:50 (UTC+2), Sverre Moe escribió:
>>>>>>
>>>>>> I was unable to determine something from the stack output
>>>>>> Here is the result: 
>>>>>> https://fastthread.io/my-thread-report.jsp?p=c2hhcmVkLzIwMTkvMDcvMjkvLS1qc3RhY2sudHh0LS05LTE2LTI3
>>>>>>
>>>>>> torsdag 18. juli 2019 11.28.06 UTC+2 skrev Sverre Moe følgende:
>>>>>>>
>>>>>>> There is no such reference in my jstack output.
>>>>>>> The output says no deadlock detected.
>>>>>>> I will try that site for analyzing the jstack.
>>>>>>>
>>>>>>> Even a normal running Jenkins has many BLOCKED threads. If that is 
>>>>>>> normal I don't know.
>>>>>>>
>>>>>>> We have a test Jenkins instance running on Java 11. That one does 
>>>>>>> not have any BLOCKED threads.
>>>>>>> Our production Jenkins is running Java 8u181.
>>>>>>>
>>>>>>> torsdag 18. juli 2019 11.04.16 UTC+2 skrev Ivan Fernandez Calvo 
>>>>>>> følgende:
>>>>>>>>
>>>>>>>> In that dump I can not see which thread is blocking the others, the 
>>>>>>>> jstack output has a reference on each thread that said what thread is 
>>>>>>>> the 
>>>>>>>> blocker on each thread (- locked <0x> a java.lang.Object), 
>>>>>>>> you can try to analyze those thread dump with 
>>>>>>>> https://fastthread.io/index.jsp or other online tools to see if 
>>>>>>>> you see something relevant, it looks like there is a deadlock.
>>>>>>>>
>>>>>>>> https://dzone.com/articles/how-to-read-a-thread-dump
>>>>>>>>
>>>>>>> -- 
>>>> 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/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/jenkinsci-users/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>> -- 
>>> Website: http://earl-of-code.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/d6699e75-4a3c-4125-8b5d-4df0fc12fb47%40googlegroups.com.

Re: Memory issues with Jenkins

[Sverre Moe]

Sadly I was mistaken. We do not use NFS for JENKINS_HOME.

We do however use NFS for the location where builds copy the RPM build 
artifacts.

mandag 5. august 2019 22.17.46 UTC+2 skrev Ivan Fernandez Calvo følgende:
>
> Hi, 
>
> Severe has another email thread open, I think it is the same Jenkins 
> instance 
> https://groups.google.com/d/msgid/jenkinsci-users/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com?utm_medium=email&utm_source=footer.
>  
> I dunno what happens on your instance but probably it isn’t better that you 
> open another email thread with the description of your issue

-- 
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/81039869-a11d-47e0-9c8b-7c2b4774da36%40googlegroups.com.

Gradle Tool Failed Download

[Sverre Moe]

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 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.f

Re: Gradle Tool Failed Download

[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.Fi

Re: Gradle Tool Failed Download

[Sverre Moe]

(ProxyConfiguration.java:285)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:924)
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 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)


onsdag 7. august 2019 19.28.15 UTC+2 skrev Mark Waite følgende:
>
> 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.se

Re: Gradle Tool Failed Download

[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:5

Re: Gradle Tool Failed Download

[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)
>&g

Re: Gradle Tool Failed Download

[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(Fil

Re: Gradle Tool Failed Download

[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(

Re: Gradle Tool Failed Download

[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.grad

Re: Memory issues with Jenkins

[Sverre Moe]

We got an 30 minute free CloudBees support. It was too short to dig deeper 
to find the problem, but the person I was talking to (after examining our 
logs) mentioned what he thought was the problem and gave a suggestion.

We should not use Jenkins master at all for builds (allocated with the 
node("master") step). We had 15 Executors for Jenkins master.

We could also try to Increase limits of hard nofile and nproc for jenkins 
user, but the main recomondation was to remove all Executors for Jenkins 
master.
> /etc/security/limits.conf
jenkins  softcoreunlimited 
jenkins  hardcoreunlimited 
jenkins  softfsize   unlimited 
jenkins  hardfsize   unlimited 
jenkins  softnofile  4096 
jenkins  hardnofile  10240 #Was 8192
jenkins  softnproc   30654 
jenkins  hardnproc   60654 #Was 30654


To remove Jenkins master Executors will take some time. We use Jenkins 
master when we publish our build artifacts RPMs to our NFS file storage. 
Since our RPM NFS is only attached to the Jenkins master it is not possible 
at the moment. Unless we can use any other agent, then do a SCP onto our 
Jenkins master with the RPM artifacts.


We had a few other circumstances where we used Jenkins master. Like 
checking out a file to determine which build agent to actually use. These I 
have already changed to use any available build agent instead.

tirsdag 6. august 2019 09.48.50 UTC+2 skrev Sverre Moe følgende:
>
> Sadly I was mistaken. We do not use NFS for JENKINS_HOME.
>
> We do however use NFS for the location where builds copy the RPM build 
> artifacts.
>
> mandag 5. august 2019 22.17.46 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>
>> Hi, 
>>
>> Severe has another email thread open, I think it is the same Jenkins 
>> instance 
>> https://groups.google.com/d/msgid/jenkinsci-users/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com?utm_medium=email&utm_source=footer.
>>  
>> I dunno what happens on your instance but probably it isn’t better that you 
>> open another email thread with the description of your issue
>
>

-- 
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/3e728790-b2f5-4ae1-a9fe-512a5c912d61%40googlegroups.com.

Re: Memory issues with Jenkins

[Sverre Moe]

I only have the option to downgrade to 1.18 of Server Sent Events (SSE) 
Gateway Plugin
I would have to download the 1.17 and manually downgrade it.

>From the discussions it seems I also need to downgrade BlueOcean to 1.17
> Downgrading to BlueOcean 1.17 (which in turn uses sse-gateway 1.17) 
appears to have resolved our issue

This would be much more work. I would need to install all the BlueOcean 
1.17 manually as I can only downgrade to 1.18.0

I might be willing to try this, even with the risk 
of https://issues.jenkins-ci.org/browse/JENKINS-51057

I am running SSE 1.19, and have previously recorded jstack from Jenkins 
PID. I could not find any EventDispatcher.retryProcessor \t

onsdag 14. august 2019 15.38.17 UTC+2 skrev Devin Nusbaum følgende:
>
> I have not read the whole thread in detail, but the “Unable to create new 
> native thread” OutOfMemoryErrors from your original thread where one of the 
> stack traces involves 
> org.jenkinsci.plugins.ssegateway.sse.EventDispatcher.scheduleRetryQueueProcessing
>  looks 
> like it could be related to 
> https://issues.jenkins-ci.org/browse/JENKINS-58684, which is a thread 
> leak caused by the SSE Gateway Plugin. You could try reverting the SSE 
> Gateway Plugin to version 1.17 to see if that helps, although that might 
> reintroduce a different, somewhat rarer memory leak (
> https://issues.jenkins-ci.org/browse/JENKINS-51057). To test my 
> hypothesis, if you are running SSE Gateway Plugin version 1.19, you can 
> collect thread dumps over time and see if you seem to have a large number 
> of threads named “EventDispatcher.retryProcessor” (unfortunately in version 
> 1.18 and below the threads are automatically named “Timer #n”, which is 
> less useful), which would confirm that you are hitting JENKINS-58684 
> <https://issues.jenkins-ci.org/browse/JENKINS-58684>.
>
> The advice to stop building on master is definitely a good idea as well.
>
> On Aug 14, 2019, at 07:11, Sverre Moe > 
> wrote:
>
> We got an 30 minute free CloudBees support. It was too short to dig deeper 
> to find the problem, but the person I was talking to (after examining our 
> logs) mentioned what he thought was the problem and gave a suggestion.
>
> We should not use Jenkins master at all for builds (allocated with the 
> node("master") step). We had 15 Executors for Jenkins master.
>
> We could also try to Increase limits of hard nofile and nproc for jenkins 
> user, but the main recomondation was to remove all Executors for Jenkins 
> master.
> > /etc/security/limits.conf
> jenkins  softcoreunlimited 
> jenkins  hardcoreunlimited 
> jenkins  softfsize   unlimited 
> jenkins  hardfsize   unlimited 
> jenkins  softnofile  4096 
> jenkins  hardnofile  10240 #Was 8192
> jenkins  softnproc   30654 
> jenkins  hardnproc   60654 #Was 30654
>
>
> To remove Jenkins master Executors will take some time. We use Jenkins 
> master when we publish our build artifacts RPMs to our NFS file storage. 
> Since our RPM NFS is only attached to the Jenkins master it is not 
> possible at the moment. Unless we can use any other agent, then do a SCP 
> onto our Jenkins master with the RPM artifacts.
>
>
> We had a few other circumstances where we used Jenkins master. Like 
> checking out a file to determine which build agent to actually use. These I 
> have already changed to use any available build agent instead.
>
> tirsdag 6. august 2019 09.48.50 UTC+2 skrev Sverre Moe følgende:
>>
>> Sadly I was mistaken. We do not use NFS for JENKINS_HOME.
>>
>> We do however use NFS for the location where builds copy the RPM build 
>> artifacts.
>>
>> mandag 5. august 2019 22.17.46 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>>
>>> Hi, 
>>>
>>> Severe has another email thread open, I think it is the same Jenkins 
>>> instance 
>>> https://groups.google.com/d/msgid/jenkinsci-users/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com?utm_medium=email&utm_source=footer.
>>>  
>>> I dunno what happens on your instance but probably it isn’t better that you 
>>> open another email thread with the description of your issue
>>
>>
> -- 
> 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/3e728790-b2f5-4ae1-a9fe-512a5c912d61%40goo

Re: Memory issues with Jenkins

[Sverre Moe]

I created a Pipeline job to run jstack every 10 minutes (though running on 
Jenkins master since that is where the Jenkins is running).

onsdag 14. august 2019 16.07.02 UTC+2 skrev Félix Belzunce Arcos følgende:
>
> Hi Sverre Moe,
>
> I am the person who talked to you this morning :-)
>
> Long term solution is to avoid building on the master to avoid performance 
> issue and the need to increase the number of processes and open files in 
> the machine where the jenkins master is located. Building on the master is 
> also not recommended from a security point of view.
>
> Short term solution would be to increase the number of new processes on 
> this machine + take thread dumps from the master each 10 minutes. For this, 
> you can create a cron freestyle job executed every 10 minutes executing 
> jstack . When the issue happens, you could take a look at the 
> latest 10 builds with their thread dumps and try to figure out what is 
> actually consuming so many threads on the master.
>
> I hope this helps,
>
>
> El miércoles, 14 de agosto de 2019, 15:38:17 (UTC+2), Devin Nusbaum 
> escribió:
>>
>> I have not read the whole thread in detail, but the “Unable to create new 
>> native thread” OutOfMemoryErrors from your original thread where one of the 
>> stack traces involves 
>> org.jenkinsci.plugins.ssegateway.sse.EventDispatcher.scheduleRetryQueueProcessing
>>  looks 
>> like it could be related to 
>> https://issues.jenkins-ci.org/browse/JENKINS-58684, which is a thread 
>> leak caused by the SSE Gateway Plugin. You could try reverting the SSE 
>> Gateway Plugin to version 1.17 to see if that helps, although that might 
>> reintroduce a different, somewhat rarer memory leak (
>> https://issues.jenkins-ci.org/browse/JENKINS-51057). To test my 
>> hypothesis, if you are running SSE Gateway Plugin version 1.19, you can 
>> collect thread dumps over time and see if you seem to have a large number 
>> of threads named “EventDispatcher.retryProcessor” (unfortunately in version 
>> 1.18 and below the threads are automatically named “Timer #n”, which is 
>> less useful), which would confirm that you are hitting JENKINS-58684 
>> <https://issues.jenkins-ci.org/browse/JENKINS-58684>.
>>
>> The advice to stop building on master is definitely a good idea as well.
>>
>> On Aug 14, 2019, at 07:11, Sverre Moe  wrote:
>>
>> We got an 30 minute free CloudBees support. It was too short to dig 
>> deeper to find the problem, but the person I was talking to (after 
>> examining our logs) mentioned what he thought was the problem and gave a 
>> suggestion.
>>
>> We should not use Jenkins master at all for builds (allocated with the 
>> node("master") step). We had 15 Executors for Jenkins master.
>>
>> We could also try to Increase limits of hard nofile and nproc for jenkins 
>> user, but the main recomondation was to remove all Executors for Jenkins 
>> master.
>> > /etc/security/limits.conf
>> jenkins  softcoreunlimited 
>> jenkins  hardcoreunlimited 
>> jenkins  softfsize   unlimited 
>> jenkins  hardfsize   unlimited 
>> jenkins  softnofile  4096 
>> jenkins  hardnofile  10240 #Was 8192
>> jenkins  softnproc   30654 
>> jenkins  hardnproc   60654 #Was 30654
>>
>>
>> To remove Jenkins master Executors will take some time. We use Jenkins 
>> master when we publish our build artifacts RPMs to our NFS file storage. 
>> Since our RPM NFS is only attached to the Jenkins master it is not 
>> possible at the moment. Unless we can use any other agent, then do a SCP 
>> onto our Jenkins master with the RPM artifacts.
>>
>>
>> We had a few other circumstances where we used Jenkins master. Like 
>> checking out a file to determine which build agent to actually use. These I 
>> have already changed to use any available build agent instead.
>>
>> tirsdag 6. august 2019 09.48.50 UTC+2 skrev Sverre Moe følgende:
>>>
>>> Sadly I was mistaken. We do not use NFS for JENKINS_HOME.
>>>
>>> We do however use NFS for the location where builds copy the RPM build 
>>> artifacts.
>>>
>>> mandag 5. august 2019 22.17.46 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>>>
>>>> Hi, 
>>>>
>>>> Severe has another email thread open, I think it is the same Jenkins 
>>>> instance 
>>>> https://groups.google.com/d/msgid/jenkinsci-users/cc2d0bdb-b

Re: Memory issues with Jenkins

[Sverre Moe]

We haven't had this OutOfMemoryError now for 3 weeks running Jenkins.

We did four things.
1) Reduced master executors from 15 to 4
2) Reduced some job steps running on "master" and instead use a build agent 
for these steps. We still have one stage/step that needs to run on master.
3 Configured many of our build agents to be offline and come online on 
demand
4 Upgraded our Jenkins server: The old server was running SLES12. We Set up 
a new VM with SLES15, and copied JENKINS_HOME over to this new server.

onsdag 14. august 2019 16.17.06 UTC+2 skrev Sverre Moe følgende:
>
> I created a Pipeline job to run jstack every 10 minutes (though running on 
> Jenkins master since that is where the Jenkins is running).
>
> onsdag 14. august 2019 16.07.02 UTC+2 skrev Félix Belzunce Arcos følgende:
>>
>> Hi Sverre Moe,
>>
>> I am the person who talked to you this morning :-)
>>
>> Long term solution is to avoid building on the master to avoid 
>> performance issue and the need to increase the number of processes and open 
>> files in the machine where the jenkins master is located. Building on the 
>> master is also not recommended from a security point of view.
>>
>> Short term solution would be to increase the number of new processes on 
>> this machine + take thread dumps from the master each 10 minutes. For this, 
>> you can create a cron freestyle job executed every 10 minutes executing 
>> jstack . When the issue happens, you could take a look at the 
>> latest 10 builds with their thread dumps and try to figure out what is 
>> actually consuming so many threads on the master.
>>
>> I hope this helps,
>>
>>
>> El miércoles, 14 de agosto de 2019, 15:38:17 (UTC+2), Devin Nusbaum 
>> escribió:
>>>
>>> I have not read the whole thread in detail, but the “Unable to create 
>>> new native thread” OutOfMemoryErrors from your original thread where one of 
>>> the stack traces involves 
>>> org.jenkinsci.plugins.ssegateway.sse.EventDispatcher.scheduleRetryQueueProcessing
>>>  looks 
>>> like it could be related to 
>>> https://issues.jenkins-ci.org/browse/JENKINS-58684, which is a thread 
>>> leak caused by the SSE Gateway Plugin. You could try reverting the SSE 
>>> Gateway Plugin to version 1.17 to see if that helps, although that might 
>>> reintroduce a different, somewhat rarer memory leak (
>>> https://issues.jenkins-ci.org/browse/JENKINS-51057). To test my 
>>> hypothesis, if you are running SSE Gateway Plugin version 1.19, you can 
>>> collect thread dumps over time and see if you seem to have a large number 
>>> of threads named “EventDispatcher.retryProcessor” (unfortunately in version 
>>> 1.18 and below the threads are automatically named “Timer #n”, which is 
>>> less useful), which would confirm that you are hitting JENKINS-58684 
>>> <https://issues.jenkins-ci.org/browse/JENKINS-58684>.
>>>
>>> The advice to stop building on master is definitely a good idea as well.
>>>
>>> On Aug 14, 2019, at 07:11, Sverre Moe  wrote:
>>>
>>> We got an 30 minute free CloudBees support. It was too short to dig 
>>> deeper to find the problem, but the person I was talking to (after 
>>> examining our logs) mentioned what he thought was the problem and gave a 
>>> suggestion.
>>>
>>> We should not use Jenkins master at all for builds (allocated with the 
>>> node("master") step). We had 15 Executors for Jenkins master.
>>>
>>> We could also try to Increase limits of hard nofile and nproc for 
>>> jenkins user, but the main recomondation was to remove all Executors for 
>>> Jenkins master.
>>> > /etc/security/limits.conf
>>> jenkins  softcoreunlimited 
>>> jenkins  hardcoreunlimited 
>>> jenkins  softfsize   unlimited 
>>> jenkins  hardfsize   unlimited 
>>> jenkins  softnofile  4096 
>>> jenkins  hardnofile  10240 #Was 8192
>>> jenkins  softnproc   30654 
>>> jenkins  hardnproc   60654 #Was 30654
>>>
>>>
>>> To remove Jenkins master Executors will take some time. We use Jenkins 
>>> master when we publish our build artifacts RPMs to our NFS file storage. 
>>> Since our RPM NFS is only attached to the Jenkins master it is not 
>>> possible at the moment. Unless we can use any other agent, then do a SCP 
>>> onto our Jenkins master with

Blue Ocean: Incomplete or missing Stages and Steps

[Sverre Moe]

Sometimes when a build fails, Blue Ocean does not show any completed or 
failed stages.

All stages show the same Step, with an incomplete build output (it is 
missing the beginning of the output).

No stepsThis stage has no steps
The entire build output is all displayed under this "step".

[image: Screenshot_20190918_133753.png]


I cannot find out why this happens some times while other builds that fail 
has no problem showing all stages and steps properly.

One failed build did not display any Stages
[image: Screenshot_20190918_134847.png]

One failed build did not display any stages and no steps, but had a show log
[image: Screenshot_20190918_134638.png]
I checked the build output and at the end it had "Creating placeholder 
flownodes because failed loading originals."


Jenkins ver. 2.176.2
Blue Ocean 1.18.1

/Sverre

-- 
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/8e7da838-a265-44ff-981e-9f7cc42895e6%40googlegroups.com.

Re: Gradle Tool Failed Download

[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 
>

Re: Gradle Tool Failed Download

[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
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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

[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
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
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

[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
>>>>  
>>>> <https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>

-- 
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

[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
>>>>>  
>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/CAMo7PtLJW%2BeMQ-509sB%2Bv%2BdAtz_%3DDudWMsiE-eCdZYfduAPcyA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>

-- 
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

[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
>>>>>>>>
>>>>>>>>

Re: Gradle Tool Failed Download

[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
 
<https://nexus.spacetec.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 

Multibranch Pipeline: Checkout fatal bad object

[Sverre Moe]

The first build of any Branch or Tag the checkout step outputs one line 
with fatal bad object, for a different git commit hash than the one checked 
out.

Anyone know what the reason for this is?

 > git fetch --tags --progress --depth=25 -- 
ssh://g...@git.company.com/apps/app-project.git 
+refs/heads/*:refs/remotes/origin/*
Checking out Revision a77b7ac906a131238f5d4586962795ba09a451ad (v1.1.13)
Commit message: "Git Commit Message"
First time build. Skipping changelog.
fatal: bad object d7989b6aa4e91962f5aeb807ad26e52432034b64
 > git config core.sparsecheckout # timeout=10
 > git checkout -f a77b7ac906a131238f5d4586962795ba09a451ad

-- 
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/53460323-98eb-4b0c-be1a-a9bccee64c02%40googlegroups.com.

Re: Multibranch Pipeline: Checkout fatal bad object

[Sverre Moe]

It seems the fatal bad object comes from the checkout of the Shared Library 
at the beginning of the pipeline.

Loading library pipeline@master

 > git fetch --no-tags --progress -- 
 > ssh://g...@git.company.com/tools/jenkins-pipeline-scripts.git 
 > +refs/heads/*:refs/remotes/origin/*

Checking out Revision d7989b6aa4e91962f5aeb807ad26e52432034b64 (master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f d7989b6aa4e91962f5aeb807ad26e52432034b64



onsdag 30. oktober 2019 11.56.22 UTC+1 skrev Sverre Moe følgende:
>
> The first build of any Branch or Tag the checkout step outputs one line 
> with fatal bad object, for a different git commit hash than the one checked 
> out.
>
> Anyone know what the reason for this is?
>
>  > git fetch --tags --progress --depth=25 -- ssh://
> g...@git.company.com/apps/app-project.git 
> +refs/heads/*:refs/remotes/origin/*
> Checking out Revision a77b7ac906a131238f5d4586962795ba09a451ad (v1.1.13)
> Commit message: "Git Commit Message"
> First time build. Skipping changelog.
> fatal: bad object d7989b6aa4e91962f5aeb807ad26e52432034b64
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f a77b7ac906a131238f5d4586962795ba09a451ad
>

-- 
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/1addbdc5-cbe3-4cbe-b9e2-7659d4bc0485%40googlegroups.com.

Coverage API: jacoco instead of jacocoAdapter

[Sverre Moe]

Publish Coverage from JaCoCo using the new Coverage API:
https://jenkins.io/blog/2018/08/17/code-coverage-api-plugin-1/

It makes a statement in this blog:

> publishCoverage adapters: [jacocoAdapter('target/site/jacoco/jacoco.xml')]
> You can also use jacoco instead of jacocoAdapter if you didn't install 
> Jacoco-Plugin.


What does this mean? That I could use the jacoco pipeline within 
publishCoverage:
jacoco classPattern: 'build/classes', execPattern: 'build/jacoco/*.exec'

In order to use the JaCoCo Adapter, I would need to run jacoco to generate 
the test report as part of my build with Gradle.
./gradlew jacocoTestReport

Then use the output from it in publishCoverage:
publishCoverage adapters: [jacocoAdapter(
'build/reports/jacoco/test/jacocoTestReport.xml')]

But if the implication of the statement made in the blog is what I think it 
means, I would not need to run jacocoTestReport.
However the Snippet generator does not allow for it, so I am not sure.


-- 
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/67662343-72e7-4c65-9e51-833bab959a71%40googlegroups.com.

RegEx Job Filter for SCM Not Working

[Sverre Moe]

I am trying to get the Regular Expression Job Filter to work with SCM 
Configuration.

Regular Expression: ssh://g...@git.company.com/various/.*
Match Value: Job SCM Configuration
Match Type: Include Matched

But no jobs are listed in the View. I want it to list all jobs that have 
SCM configuration with the various namespace.
I have also tried with the following regular expressions
.*/various/.*
./various/.

According to documentation for the View Job Filter Plugin
SCM Configuration - this one is perhaps the best bang for the buck - put in 
something like "./my-office-name/." to automatically include all jobs that 
are organized under source control already by office.

-- 
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/9b6d5470-e4e9-46d5-adc3-9ecc7a398785%40googlegroups.com.

The pipeline emailextrecipients step takes too long time

[Sverre Moe]

Calling the pipeline step emailextrecipients when there are changes takes 
too much time.
A normal git checkout that takes 10-15 seconds, will usually take 1-2 
minutes when there are changes, just because of emailextrecipients.
All I want is the authors from the current build changes. I see no reason 
why this should take so long.

I took a small look at the code for emailextrecipients, and it seems it 
looks also on previous builds.

def recipients = emailextrecipients([developers()])

Our developers want the builds to run as fast as it can. Time is precious.
I am considering removing this recipients. I already have the git 
repository maintainers I can send email notifications to if anything goes 
wrong.
The backside of removing this, is I cannot send email notifications for the 
developers, just the maintainers (and those only want notifications for 
release build, and not all continuous builds).

The reason I call emailextrecipients during the Checkout stage, is because 
that is the only stage where I have access to the git repository. Later in 
the build if it fails I do not have access to git anymore.

The emailextrecipients code does have some Debug logging. How can I enable 
this to see what it is actually doing?

I was thinking of implementing my own parsing of the change records. It 
cannot possibly take more than a few seconds to find the authors of all the 
changes.

-- 
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/de0f53c9-9512-4fd6-a258-e604412ff77a%40googlegroups.com.

Re: The pipeline emailextrecipients step takes too long time

[Sverre Moe]

Tried to configure debug
Manage Jenkins > Configure System > Extended Email Notification >Enable 
Debug

I added a System Log for "hudson.plugins.emailext" and Log Level ALL.

Hope I can find something about why it takes so long.

fredag 24. april 2020 23.20.40 UTC+2 skrev slide følgende:
>
> You can turn on debug mode in the global config for Email Ext. The code 
> isn't really doing anything major, it just looks at the changesets and get 
> the authors, so I am not sure why it would be taking that long.
>
> On Fri, Apr 24, 2020 at 1:59 PM Sverre Moe  > wrote:
>
>> Calling the pipeline step emailextrecipients when there are changes takes 
>> too much time.
>> A normal git checkout that takes 10-15 seconds, will usually take 1-2 
>> minutes when there are changes, just because of emailextrecipients.
>> All I want is the authors from the current build changes. I see no reason 
>> why this should take so long.
>>
>> I took a small look at the code for emailextrecipients, and it seems it 
>> looks also on previous builds.
>>
>> def recipients = emailextrecipients([developers()])
>>
>> Our developers want the builds to run as fast as it can. Time is precious.
>> I am considering removing this recipients. I already have the git 
>> repository maintainers I can send email notifications to if anything goes 
>> wrong.
>> The backside of removing this, is I cannot send email notifications for 
>> the developers, just the maintainers (and those only want notifications for 
>> release build, and not all continuous builds).
>>
>> The reason I call emailextrecipients during the Checkout stage, is 
>> because that is the only stage where I have access to the git repository. 
>> Later in the build if it fails I do not have access to git anymore.
>>
>> The emailextrecipients code does have some Debug logging. How can I 
>> enable this to see what it is actually doing?
>>
>> I was thinking of implementing my own parsing of the change records. It 
>> cannot possibly take more than a few seconds to find the authors of all the 
>> changes.
>>
>> -- 
>> 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/de0f53c9-9512-4fd6-a258-e604412ff77a%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/de0f53c9-9512-4fd6-a258-e604412ff77a%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> -- 
> Website: http://earl-of-code.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/fbf04c99-b61b-4109-ac21-50a77fca08c0%40googlegroups.com.

Re: The pipeline emailextrecipients step takes too long time

[Sverre Moe]

Yes it did.

Just one simple little commit, and Checkout took a little over 1 minute

[Pipeline] emailextrecipients 
<https://build-ci.spacetec.no:8443/view/All%20meosconfig/job/meosconfig-dashboard-layouts/job/master/168/console#>
  Collecting change authors...
build: 168
  adding author: Sverre Moe

Adding Sverre Moe with address sve...@company.com
Analyzing: sve...@company.com
Looking for: sve...@company.com
starting at: 0
firstFoundIdx: 0
firstFoundIdx-substring: sve...@company.com
=> found type: 0
Analyzing: sve...@company.com
Looking for: sve...@company.com
starting at: 0
firstFoundIdx: 0
firstFoundIdx-substring: sve...@company.com
=> found type: 0
Analyzing: sve...@company.com
Looking for: sve...@company.com
starting at: 0
firstFoundIdx: 0
firstFoundIdx-substring: sve...@company.com
=> found type: 0


lørdag 25. april 2020 21.51.25 UTC+2 skrev slide følgende:
>
> I think the debug logs will just go to the build log.
>
> On Sat, Apr 25, 2020, 11:58 Sverre Moe > 
> wrote:
>
>> Tried to configure debug
>> Manage Jenkins > Configure System > Extended Email Notification >Enable 
>> Debug
>>
>> I added a System Log for "hudson.plugins.emailext" and Log Level ALL.
>>
>> Hope I can find something about why it takes so long.
>>
>> fredag 24. april 2020 23.20.40 UTC+2 skrev slide følgende:
>>>
>>> You can turn on debug mode in the global config for Email Ext. The code 
>>> isn't really doing anything major, it just looks at the changesets and get 
>>> the authors, so I am not sure why it would be taking that long.
>>>
>>> On Fri, Apr 24, 2020 at 1:59 PM Sverre Moe  wrote:
>>>
>>>> Calling the pipeline step emailextrecipients when there are changes 
>>>> takes too much time.
>>>> A normal git checkout that takes 10-15 seconds, will usually take 1-2 
>>>> minutes when there are changes, just because of emailextrecipients.
>>>> All I want is the authors from the current build changes. I see no 
>>>> reason why this should take so long.
>>>>
>>>> I took a small look at the code for emailextrecipients, and it seems it 
>>>> looks also on previous builds.
>>>>
>>>> def recipients = emailextrecipients([developers()])
>>>>
>>>> Our developers want the builds to run as fast as it can. Time is 
>>>> precious.
>>>> I am considering removing this recipients. I already have the git 
>>>> repository maintainers I can send email notifications to if anything goes 
>>>> wrong.
>>>> The backside of removing this, is I cannot send email notifications for 
>>>> the developers, just the maintainers (and those only want notifications 
>>>> for 
>>>> release build, and not all continuous builds).
>>>>
>>>> The reason I call emailextrecipients during the Checkout stage, is 
>>>> because that is the only stage where I have access to the git repository. 
>>>> Later in the build if it fails I do not have access to git anymore.
>>>>
>>>> The emailextrecipients code does have some Debug logging. How can I 
>>>> enable this to see what it is actually doing?
>>>>
>>>> I was thinking of implementing my own parsing of the change records. It 
>>>> cannot possibly take more than a few seconds to find the authors of all 
>>>> the 
>>>> changes.
>>>>
>>>> -- 
>>>> 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/de0f53c9-9512-4fd6-a258-e604412ff77a%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/jenkinsci-users/de0f53c9-9512-4fd6-a258-e604412ff77a%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>> -- 
>>> Website: http://earl-of-code.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 jenkins...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/fbf04c99-b61b-4109-ac21-50a77fca08c0%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/fbf04c99-b61b-4109-ac21-50a77fca08c0%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/d96643c8-b4d1-46bc-9339-c5094dd2d3c7%40googlegroups.com.

Re: The pipeline emailextrecipients step takes too long time

[Sverre Moe]

I added println how much time it used.
Mostly it uses only a few milliseconds.
In one case so far, It used a little over 6 milliseconds.

The output from the emailextrecipients debug was no different from those 
build that only took a few milliseconds.

søndag 26. april 2020 10.15.51 UTC+2 skrev Sverre Moe følgende:
>
> Yes it did.
>
> Just one simple little commit, and Checkout took a little over 1 minute
>
> [Pipeline] emailextrecipients 
> <https://build-ci.spacetec.no:8443/view/All%20meosconfig/job/meosconfig-dashboard-layouts/job/master/168/console#>
>   Collecting change authors...
> build: 168
>   adding author: Sverre Moe
>
> Adding Sverre Moe with address sve...@company.com
> Analyzing: sve...@company.com
> Looking for: sve...@company.com
>   starting at: 0
>   firstFoundIdx: 0
>   firstFoundIdx-substring: sve...@company.com
>   => found type: 0
> Analyzing: sve...@company.com
> Looking for: sve...@company.com
>   starting at: 0
>   firstFoundIdx: 0
>   firstFoundIdx-substring: sve...@company.com
>   => found type: 0
> Analyzing: sve...@company.com
> Looking for: sve...@company.com
>   starting at: 0
>   firstFoundIdx: 0
>   firstFoundIdx-substring: sve...@company.com
>   => found type: 0
>
>
> lørdag 25. april 2020 21.51.25 UTC+2 skrev slide følgende:
>>
>> I think the debug logs will just go to the build log.
>>
>> On Sat, Apr 25, 2020, 11:58 Sverre Moe  wrote:
>>
>>> Tried to configure debug
>>> Manage Jenkins > Configure System > Extended Email Notification >Enable 
>>> Debug
>>>
>>> I added a System Log for "hudson.plugins.emailext" and Log Level ALL.
>>>
>>> Hope I can find something about why it takes so long.
>>>
>>> fredag 24. april 2020 23.20.40 UTC+2 skrev slide følgende:
>>>>
>>>> You can turn on debug mode in the global config for Email Ext. The code 
>>>> isn't really doing anything major, it just looks at the changesets and get 
>>>> the authors, so I am not sure why it would be taking that long.
>>>>
>>>> On Fri, Apr 24, 2020 at 1:59 PM Sverre Moe  wrote:
>>>>
>>>>> Calling the pipeline step emailextrecipients when there are changes 
>>>>> takes too much time.
>>>>> A normal git checkout that takes 10-15 seconds, will usually take 1-2 
>>>>> minutes when there are changes, just because of emailextrecipients.
>>>>> All I want is the authors from the current build changes. I see no 
>>>>> reason why this should take so long.
>>>>>
>>>>> I took a small look at the code for emailextrecipients, and it seems 
>>>>> it looks also on previous builds.
>>>>>
>>>>> def recipients = emailextrecipients([developers()])
>>>>>
>>>>> Our developers want the builds to run as fast as it can. Time is 
>>>>> precious.
>>>>> I am considering removing this recipients. I already have the git 
>>>>> repository maintainers I can send email notifications to if anything goes 
>>>>> wrong.
>>>>> The backside of removing this, is I cannot send email notifications 
>>>>> for the developers, just the maintainers (and those only want 
>>>>> notifications 
>>>>> for release build, and not all continuous builds).
>>>>>
>>>>> The reason I call emailextrecipients during the Checkout stage, is 
>>>>> because that is the only stage where I have access to the git repository. 
>>>>> Later in the build if it fails I do not have access to git anymore.
>>>>>
>>>>> The emailextrecipients code does have some Debug logging. How can I 
>>>>> enable this to see what it is actually doing?
>>>>>
>>>>> I was thinking of implementing my own parsing of the change records. 
>>>>> It cannot possibly take more than a few seconds to find the authors of 
>>>>> all 
>>>>> the changes.
>>>>>
>>>>> -- 
>>>>> 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/de0f5

Re: The pipeline emailextrecipients step takes too long time

[Sverre Moe]

How can I add timestamp to the debug output?

søndag 26. april 2020 18.30.59 UTC+2 skrev slide følgende:
>
> Can you add timestamps? It's hard to tell from what you posted when things 
> are occurring.
>
> On Sun, Apr 26, 2020, 01:16 Sverre Moe > 
> wrote:
>
>> Yes it did.
>>
>> Just one simple little commit, and Checkout took a little over 1 minute
>>
>> [Pipeline] emailextrecipients 
>> <https://build-ci.spacetec.no:8443/view/All%20meosconfig/job/meosconfig-dashboard-layouts/job/master/168/console#>
>>   Collecting change authors...
>> build: 168
>>   adding author: Sverre Moe
>>
>> Adding Sverre Moe with address sve...@company.com 
>> Analyzing: sve...@company.com 
>> Looking for: sve...@company.com 
>>  starting at: 0
>>  firstFoundIdx: 0
>>  firstFoundIdx-substring: sve...@company.com 
>>  => found type: 0
>> Analyzing: sve...@company.com 
>> Looking for: sve...@company.com 
>>  starting at: 0
>>  firstFoundIdx: 0
>>  firstFoundIdx-substring: sve...@company.com 
>>  => found type: 0
>> Analyzing: sve...@company.com 
>> Looking for: sve...@company.com 
>>  starting at: 0
>>  firstFoundIdx: 0
>>  firstFoundIdx-substring: sve...@company.com 
>>  => found type: 0
>>
>>
>> lørdag 25. april 2020 21.51.25 UTC+2 skrev slide følgende:
>>>
>>> I think the debug logs will just go to the build log.
>>>
>>> On Sat, Apr 25, 2020, 11:58 Sverre Moe  wrote:
>>>
>>>> Tried to configure debug
>>>> Manage Jenkins > Configure System > Extended Email Notification >Enable 
>>>> Debug
>>>>
>>>> I added a System Log for "hudson.plugins.emailext" and Log Level ALL.
>>>>
>>>> Hope I can find something about why it takes so long.
>>>>
>>>> fredag 24. april 2020 23.20.40 UTC+2 skrev slide følgende:
>>>>>
>>>>> You can turn on debug mode in the global config for Email Ext. The 
>>>>> code isn't really doing anything major, it just looks at the changesets 
>>>>> and 
>>>>> get the authors, so I am not sure why it would be taking that long.
>>>>>
>>>>> On Fri, Apr 24, 2020 at 1:59 PM Sverre Moe  wrote:
>>>>>
>>>>>> Calling the pipeline step emailextrecipients when there are changes 
>>>>>> takes too much time.
>>>>>> A normal git checkout that takes 10-15 seconds, will usually take 1-2 
>>>>>> minutes when there are changes, just because of emailextrecipients.
>>>>>> All I want is the authors from the current build changes. I see no 
>>>>>> reason why this should take so long.
>>>>>>
>>>>>> I took a small look at the code for emailextrecipients, and it seems 
>>>>>> it looks also on previous builds.
>>>>>>
>>>>>> def recipients = emailextrecipients([developers()])
>>>>>>
>>>>>> Our developers want the builds to run as fast as it can. Time is 
>>>>>> precious.
>>>>>> I am considering removing this recipients. I already have the git 
>>>>>> repository maintainers I can send email notifications to if anything 
>>>>>> goes 
>>>>>> wrong.
>>>>>> The backside of removing this, is I cannot send email notifications 
>>>>>> for the developers, just the maintainers (and those only want 
>>>>>> notifications 
>>>>>> for release build, and not all continuous builds).
>>>>>>
>>>>>> The reason I call emailextrecipients during the Checkout stage, is 
>>>>>> because that is the only stage where I have access to the git 
>>>>>> repository. 
>>>>>> Later in the build if it fails I do not have access to git anymore.
>>>>>>
>>>>>> The emailextrecipients code does have some Debug logging. How can I 
>>>>>> enable this to see what it is actually doing?
>>>>>>
>>>>>> I was thinking of implementing my own parsing of the change records. 
>>>>>> It cannot possibly take more than a few seconds to find the authors of 
>>>>>> all 
>>>>>> the changes.
>>>>>>
>>>>>> -- 
>>>>>> You received this message because yo

Re: The pipeline emailextrecipients step takes too long time

[Sverre Moe]

How so?

Does emailextrecipient do a DNS lookup on each author it can find?

søndag 26. april 2020 20.12.03 UTC+2 skrev jeremy mordkoff følgende:
>
> check that DNS is working. I've seen huge delays on basic ops when DNS 
> lookups are timing out. Check forward and reverse lookups. 
>
>
>
> On Sunday, April 26, 2020 at 12:30:59 PM UTC-4, slide wrote:
>>
>> Can you add timestamps? It's hard to tell from what you posted when 
>> things are occurring.
>>
>> On Sun, Apr 26, 2020, 01:16 Sverre Moe  wrote:
>>
>>> Yes it did.
>>>
>>> Just one simple little commit, and Checkout took a little over 1 minute
>>>
>>> [Pipeline] emailextrecipients 
>>> <https://build-ci.spacetec.no:8443/view/All%20meosconfig/job/meosconfig-dashboard-layouts/job/master/168/console#>
>>>   Collecting change authors...
>>> build: 168
>>>   adding author: Sverre Moe
>>>
>>> Adding Sverre Moe with address sve...@company.com
>>> Analyzing: sve...@company.com
>>> Looking for: sve...@company.com
>>> starting at: 0
>>> firstFoundIdx: 0
>>> firstFoundIdx-substring: sve...@company.com
>>> => found type: 0
>>> Analyzing: sve...@company.com
>>> Looking for: sve...@company.com
>>> starting at: 0
>>> firstFoundIdx: 0
>>> firstFoundIdx-substring: sve...@company.com
>>> => found type: 0
>>> Analyzing: sve...@company.com
>>> Looking for: sve...@company.com
>>> starting at: 0
>>> firstFoundIdx: 0
>>> firstFoundIdx-substring: sve...@company.com
>>> => found type: 0
>>>
>>>
>>> lørdag 25. april 2020 21.51.25 UTC+2 skrev slide følgende:
>>>>
>>>> I think the debug logs will just go to the build log.
>>>>
>>>> On Sat, Apr 25, 2020, 11:58 Sverre Moe  wrote:
>>>>
>>>>> Tried to configure debug
>>>>> Manage Jenkins > Configure System > Extended Email Notification 
>>>>> >Enable Debug
>>>>>
>>>>> I added a System Log for "hudson.plugins.emailext" and Log Level ALL.
>>>>>
>>>>> Hope I can find something about why it takes so long.
>>>>>
>>>>> fredag 24. april 2020 23.20.40 UTC+2 skrev slide følgende:
>>>>>>
>>>>>> You can turn on debug mode in the global config for Email Ext. The 
>>>>>> code isn't really doing anything major, it just looks at the changesets 
>>>>>> and 
>>>>>> get the authors, so I am not sure why it would be taking that long.
>>>>>>
>>>>>> On Fri, Apr 24, 2020 at 1:59 PM Sverre Moe  wrote:
>>>>>>
>>>>>>> Calling the pipeline step emailextrecipients when there are changes 
>>>>>>> takes too much time.
>>>>>>> A normal git checkout that takes 10-15 seconds, will usually take 
>>>>>>> 1-2 minutes when there are changes, just because of emailextrecipients.
>>>>>>> All I want is the authors from the current build changes. I see no 
>>>>>>> reason why this should take so long.
>>>>>>>
>>>>>>> I took a small look at the code for emailextrecipients, and it seems 
>>>>>>> it looks also on previous builds.
>>>>>>>
>>>>>>> def recipients = emailextrecipients([developers()])
>>>>>>>
>>>>>>> Our developers want the builds to run as fast as it can. Time is 
>>>>>>> precious.
>>>>>>> I am considering removing this recipients. I already have the git 
>>>>>>> repository maintainers I can send email notifications to if anything 
>>>>>>> goes 
>>>>>>> wrong.
>>>>>>> The backside of removing this, is I cannot send email notifications 
>>>>>>> for the developers, just the maintainers (and those only want 
>>>>>>> notifications 
>>>>>>> for release build, and not all continuous builds).
>>>>>>>
>>>>>>> The reason I call emailextrecipients during the Checkout stage, is 
>>>>>>> because that is the only stage where I have access to the git 
>>>>>>> repository. 
>>>>>>> Later in the build if it fails I do not have access to git anymore

Re: The pipeline emailextrecipients step takes too long time

[Sverre Moe]

Well at this point I am not sending any email, yet.
I am looking up recipients from change set, so I can use that later when/if 
I send email for failed builds.

Does emailextrecipients do the lookup itself, or is it done when calling 
mail step?

mandag 27. april 2020 01.12.48 UTC+2 skrev Jeremy Mordkoff følgende:
>
> sending email always involves a forward lookup and many mail servers do a 
> reverse lookup on the sender's IP. 
>
>
>
> *--- Jeremy Mordkoff*
> Director of Engineering Services
> <https://www.riftio.com>
> RIFT, inc
> 900 Chelmsford Street,  4th floor, tower 3
> Lowell, MA 01851
> 1.978.257.2183 (*cell*)
> <http://www.riftio.com>www.riftio.com
> --
> *From:* jenkins...@googlegroups.com  <
> jenkins...@googlegroups.com > on behalf of Sverre Moe <
> sver...@gmail.com >
> *Sent:* Sunday, April 26, 2020 3:32 PM
> *To:* Jenkins Users >
> *Subject:* Re: The pipeline emailextrecipients step takes too long time 
>  
> How so? 
>
> Does emailextrecipient do a DNS lookup on each author it can find?
>
> søndag 26. april 2020 20.12.03 UTC+2 skrev jeremy mordkoff følgende: 
>
> check that DNS is working. I've seen huge delays on basic ops when DNS 
> lookups are timing out. Check forward and reverse lookups.  
>
>
>
> On Sunday, April 26, 2020 at 12:30:59 PM UTC-4, slide wrote: 
>
> Can you add timestamps? It's hard to tell from what you posted when things 
> are occurring.
>
> On Sun, Apr 26, 2020, 01:16 Sverre Moe  wrote:
>
> Yes it did. 
>
> Just one simple little commit, and Checkout took a little over 1 minute
>
> [Pipeline] emailextrecipients 
> <https://build-ci.spacetec.no:8443/view/All%20meosconfig/job/meosconfig-dashboard-layouts/job/master/168/console#>
>   Collecting change authors...
> build: 168
>   adding author: Sverre Moe
>
> Adding Sverre Moe with address sve...@company.com
> Analyzing: sve...@company.com
> Looking for: sve...@company.com
>   starting at: 0
>   firstFoundIdx: 0
>   firstFoundIdx-substring: sve...@company.com
>   => found type: 0
> Analyzing: sve...@company.com
> Looking for: sve...@company.com
>   starting at: 0
>   firstFoundIdx: 0
>   firstFoundIdx-substring: sve...@company.com
>   => found type: 0
> Analyzing: sve...@company.com
> Looking for: sve...@company.com
>   starting at: 0
>   firstFoundIdx: 0
>   firstFoundIdx-substring: sve...@company.com
>   => found type: 0
>
>
> lørdag 25. april 2020 21.51.25 UTC+2 skrev slide følgende: 
>
> I think the debug logs will just go to the build log.
>
> On Sat, Apr 25, 2020, 11:58 Sverre Moe  wrote:
>
> Tried to configure debug
> Manage Jenkins > Configure System > Extended Email Notification >Enable 
> Debug
>
> I added a System Log for "hudson.plugins.emailext" and Log Level ALL.
>
> Hope I can find something about why it takes so long.
>
> fredag 24. april 2020 23.20.40 UTC+2 skrev slide følgende: 
>
> You can turn on debug mode in the global config for Email Ext. The code 
> isn't really doing anything major, it just looks at the changesets and get 
> the authors, so I am not sure why it would be taking that long.
>
> On Fri, Apr 24, 2020 at 1:59 PM Sverre Moe  wrote:
>
> Calling the pipeline step emailextrecipients when there are changes takes 
> too much time.
> A normal git checkout that takes 10-15 seconds, will usually take 1-2 
> minutes when there are changes, just because of emailextrecipients.
> All I want is the authors from the current build changes. I see no reason 
> why this should take so long.
>
> I took a small look at the code for emailextrecipients, and it seems it 
> looks also on previous builds.
>
> def recipients = emailextrecipients([developers()])
>
> Our developers want the builds to run as fast as it can. Time is precious.
> I am considering removing this recipients. I already have the git 
> repository maintainers I can send email notifications to if anything goes 
> wrong.
> The backside of removing this, is I cannot send email notifications for 
> the developers, just the maintainers (and those only want notifications for 
> release build, and not all continuous builds).
>
> The reason I call emailextrecipients during the Checkout stage, is because 
> that is the only stage where I have access to the git repository. Later in 
> the build if it fails I do not have access to git anymore.
>
> The emailextrecipients code does have some Debug logging. How can I enable 
> this to see what it is actually doing?
>
> I was thinking of implementing my own parsing of the change recor

Re: The pipeline emailextrecipients step takes too long time

[Sverre Moe]

This plugin you are mentioning?
https://plugins.jenkins.io/timestamper/

mandag 27. april 2020 00.30.33 UTC+2 skrev Jan Monterrubio følgende:
>
> Use the timestamps plugin , it has a mode to add global timestamps or you 
> can configure options per pipeline 
>
> On Sun, Apr 26, 2020 at 14:32 Sverre Moe > 
> wrote:
>
>> How can I add timestamp to the debug output?
>>
>> søndag 26. april 2020 18.30.59 UTC+2 skrev slide følgende:
>>>
>>> Can you add timestamps? It's hard to tell from what you posted when 
>>> things are occurring.
>>>
>>> On Sun, Apr 26, 2020, 01:16 Sverre Moe  wrote:
>>>
>>>> Yes it did.
>>>>
>>>> Just one simple little commit, and Checkout took a little over 1 minute
>>>>
>>>> [Pipeline] emailextrecipients 
>>>> <https://build-ci.spacetec.no:8443/view/All%20meosconfig/job/meosconfig-dashboard-layouts/job/master/168/console#>
>>>>   Collecting change authors...
>>>> build: 168
>>>>   adding author: Sverre Moe
>>>>
>>>> Adding Sverre Moe with address sve...@company.com
>>>> Analyzing: sve...@company.com
>>>> Looking for: sve...@company.com
>>>>starting at: 0
>>>>firstFoundIdx: 0
>>>>firstFoundIdx-substring: sve...@company.com
>>>>=> found type: 0
>>>> Analyzing: sve...@company.com
>>>> Looking for: sve...@company.com
>>>>starting at: 0
>>>>firstFoundIdx: 0
>>>>firstFoundIdx-substring: sve...@company.com
>>>>=> found type: 0
>>>> Analyzing: sve...@company.com
>>>> Looking for: sve...@company.com
>>>>starting at: 0
>>>>firstFoundIdx: 0
>>>>firstFoundIdx-substring: sve...@company.com
>>>>=> found type: 0
>>>>
>>>>
>>>> lørdag 25. april 2020 21.51.25 UTC+2 skrev slide følgende:
>>>>>
>>>>> I think the debug logs will just go to the build log.
>>>>>
>>>>> On Sat, Apr 25, 2020, 11:58 Sverre Moe  wrote:
>>>>>
>>>>>> Tried to configure debug
>>>>>> Manage Jenkins > Configure System > Extended Email Notification 
>>>>>> >Enable Debug
>>>>>>
>>>>>> I added a System Log for "hudson.plugins.emailext" and Log Level ALL.
>>>>>>
>>>>>> Hope I can find something about why it takes so long.
>>>>>>
>>>>>> fredag 24. april 2020 23.20.40 UTC+2 skrev slide følgende:
>>>>>>>
>>>>>>> You can turn on debug mode in the global config for Email Ext. The 
>>>>>>> code isn't really doing anything major, it just looks at the changesets 
>>>>>>> and 
>>>>>>> get the authors, so I am not sure why it would be taking that long.
>>>>>>>
>>>>>>> On Fri, Apr 24, 2020 at 1:59 PM Sverre Moe  
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Calling the pipeline step emailextrecipients when there are changes 
>>>>>>>> takes too much time.
>>>>>>>> A normal git checkout that takes 10-15 seconds, will usually take 
>>>>>>>> 1-2 minutes when there are changes, just because of emailextrecipients.
>>>>>>>> All I want is the authors from the current build changes. I see no 
>>>>>>>> reason why this should take so long.
>>>>>>>>
>>>>>>>> I took a small look at the code for emailextrecipients, and it 
>>>>>>>> seems it looks also on previous builds.
>>>>>>>>
>>>>>>>> def recipients = emailextrecipients([developers()])
>>>>>>>>
>>>>>>>> Our developers want the builds to run as fast as it can. Time is 
>>>>>>>> precious.
>>>>>>>> I am considering removing this recipients. I already have the git 
>>>>>>>> repository maintainers I can send email notifications to if anything 
>>>>>>>> goes 
>>>>>>>> wrong.
>>>>>>>> The backside of removing this, is I cannot send email notifications 
>>>>>>>> for the developers, just the maintainers (and those only want 
>>>>>>>> notificat