date:20191108

Title: Message Title


 
 
 
 

 
 
 

 
   
 Saad Azam updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60111  
 
 
  Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline   
 

  
 
 
 
 

 
Change By: 
 Saad Azam  
 
 
Issue Type: 
 Improvement Bug  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60111) Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Saad Azam assigned an issue to Andrew Bayer  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60111  
 
 
  Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline   
 

  
 
 
 
 

 
Change By: 
 Saad Azam  
 
 
Assignee: 
 Andrew Bayer  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60111) Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Saad Azam updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60111  
 
 
  Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline   
 

  
 
 
 
 

 
Change By: 
 Saad Azam  
 
 
Component/s: 
 workflow-cps-plugin  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60111) Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Saad Azam updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60111  
 
 
  Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline   
 

  
 
 
 
 

 
Change By: 
 Saad Azam  
 
 
Component/s: 
 pipeline  
 
 
Component/s: 
 workflow-cps-plugin  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60111) Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Saad Azam updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60111  
 
 
  Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline   
 

  
 
 
 
 

 
Change By: 
 Saad Azam  
 
 
Component/s: 
 pipeline  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60111) Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Saad Azam updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60111  
 
 
  Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline   
 

  
 
 
 
 

 
Change By: 
 Saad Azam  
 
 
Component/s: 
 workflow-cps-plugin  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60111) Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Saad Azam updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60111  
 
 
  Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline   
 

  
 
 
 
 

 
Change By: 
 Saad Azam  
 
 
Priority: 
 Minor Major  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60111) Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Saad Azam updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60111  
 
 
  Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline   
 

  
 
 
 
 

 
Change By: 
 Saad Azam  
 
 
Attachment: 
 demo_pipeline.jpg  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60111) Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Saad Azam updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60111  
 
 
  Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline   
 

  
 
 
 
 

 
Change By: 
 Saad Azam  
 

  
 
 
 
 

 
 I recently setup a new Jenkins server on Linux. I am facing issues with the pipeline execution time. I see the pipeline script takes much longer to execute when triggered by a user. On the contrary it is quite fast when built periodically by a time trigger. This is causing a huge overhead for complicated pipelines we are suing in our projects. As an example see the following example pipeline I created for demo  (see the attached image for the results) :{code:java}pipeline {agent {label "${NODE_LABEL}"}/*triggers {pollSCM('H/2 * * * *')}*/stages {stage('One'){steps {echo 'First stage...'}}stage('Two'){steps {echo 'Second stage...'}}stage('Three'){steps {echo 'Third stage...'}}stage('Four'){steps {echo 'Fourth stage...'}}stage('Five'){steps {echo 'Fifth stage...'}}}}{code} After looking into the jenkins.log file, the difference I see between the two runs is that at every stage execution in the slower build (executed by the user) there is warning due to an exception in CpsFlowExecution as below:{code:java}2019-11-08 16:21:31.222+ [id=48479] INFO hudson.model.AsyncPeriodicWork$1#run: Started Download metadata2019-11-08 16:21:31.222+ [id=48479] INFO hudson.model.AsyncPeriodicWork$1#run: Started Download metadata2019-11-08 16:21:32.036+ [id=48479] INFO h.m.DownloadService$Downloadable#load: Obtained the updated data file for hudson.tasks.Maven.MavenInstaller2019-11-08 16:21:32.412+ [id=48479] INFO h.m.DownloadService$Downloadable#load: Obtained the updated data file for hudson.plugins.gradle.GradleInstaller2019-11-08 16:21:32.686+ [id=48479] INFO h.m.DownloadService$Downloadable#load: Obtained the updated data file for hudson.tasks.Ant.AntInstaller2019-11-08 16:21:33.805+ [id=48479] INFO h.m.DownloadService$Downloadable#load: Obtained the updated data file for hudson.tools.JDKInstaller2019-11-08 16:21:33.805+ [id=48479] INFO hudson.model.AsyncPeriodicWork$1#run: Finished Download metadata. 2,583 ms2019-11-08 16:21:35.616+ [id=22366] WARNING o.j.p.w.cps.CpsFlowExecution#blocksRestart: Not blocking restart due to problem checking running steps in CpsFlowExecution[Owner[test_pipeline_general/2:test_pipeline_general #2]]java.util.concurrent.TimeoutException: Timeout waiting for task. at com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:259) at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:91) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.blocksRestart(CpsFlowExecution.java:940) at org.jenkinsci.plugins.workflow.j

[JIRA] (JENKINS-60111) Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Saad Azam created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60111  
 
 
  Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 pipeline  
 
 
Created: 
 2019-11-08 16:44  
 
 
Environment: 
 Jenkins ver. 2.190.1  Master OS: RedHat Linux  Java version 1.8  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Saad Azam  
 

  
 
 
 
 

 
 I recently setup a new Jenkins server on Linux. I am facing issues with the pipeline execution time. I see the pipeline script takes much longer to execute when triggered by a user. On the contrary it is quite fast when built periodically by a time trigger. This is causing a huge overhead for complicated pipelines we are suing in our projects. As an example see the following example pipeline I created for demo: 

 

pipeline {
agent {label "${NODE_LABEL}"}
/*
triggers {
pollSCM('H/2 * * * *')
}
*/
stages {
stage('One'){
steps {
echo 'First stage...'
}
}
stage('Two'){
steps {
echo 'Second stage...'
}
}
stage('Three'){
steps {
echo 'Third stage...'
}
}
stage('Four'){
steps {
echo 'Fourth stage...'
}
}
stage('Five'){
steps {
echo 'Fifth stage...'
}
}
}
}
 

  After looking into the jenkins.log file, the

[JIRA] (JENKINS-60111) Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Saad Azam updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60111  
 
 
  Pipeline extremely slow when triggered by a user in comparison with the time triggered pipeline   
 

  
 
 
 
 

 
Change By: 
 Saad Azam  
 
 
Attachment: 
 demo_pipeline.jpg  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60103) Cannot send junit results to Octane

2019-11-08 Thread radislav.berkov...@hpe.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Radi Berkovich commented on  JENKINS-60103  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cannot send junit results to Octane   
 

  
 
 
 
 

 
 All other slave are not on docker? What about java? is it different on other slaves?    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-59218) NullPointerException in logparser buildDataSet(LogParserAction.java:147)

2019-11-08 Thread carsten.pfeif...@gebit.de (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Carsten Pfeiffer commented on  JENKINS-59218  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: NullPointerException in logparser buildDataSet(LogParserAction.java:147)   
 

  
 
 
 
 

 
 PR available at https://github.com/jenkinsci/log-parser-plugin/pull/27  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-22795) git plugin cleans workspace on initial clone

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite edited a comment on  JENKINS-22795  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: git plugin cleans workspace on initial clone   
 

  
 
 
 
 

 
 [~roydahan] you may want to check the agent where that job is running.  The removal of the contents only happens on the  *  initial *  creation of the workspace, not on later requests to  *  update an existing workspace * .  Something on the agent running the build may be causing the plugin to believe that it needs to perform a fresh clone rather than performing an incremental update.If you're using a Pipeline, you may also want to check the Pipeline definition that it does not include a separate call to deleteDir().  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-22795) git plugin cleans workspace on initial clone

2019-11-08 Thread mi+jenkins-2...@aldan.algebra.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite edited a comment on  JENKINS-22795  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: git plugin cleans workspace on initial clone   
 

  
 
 
 
 

 
 [~roydahan] you may want to check the agent where that job is running.  The removal of the contents only happens on the *initial* creation of the workspace,  *  not *  on later requests to *update an existing workspace*.  Something on the agent running the build may be causing the plugin to believe that it needs to perform a fresh clone rather than performing an incremental update.If you're using a Pipeline, you may also want to check the Pipeline definition that it does not include a separate call to deleteDir().  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60103) Cannot send junit results to Octane

2019-11-08 Thread vien...@poczta.fm (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 pretbc pretbc commented on  JENKINS-60103  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cannot send junit results to Octane   
 

  
 
 
 
 

 
 Yes, i have 12 different slaves. No, issue occur only on 1 slave. Yes, for all jobs on that slave. I Run this slave using docker  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60050) Add title into the ChangeRequestSCMHead interface

2019-11-08 Thread bitwise...@gmail.com (JIRA)

Title: Message Title

Liam Newman commented on JENKINS-60050

Re: Add title into the ChangeRequestSCMHead interface

I'm sorry, but I disagree with this change. "ChangeRequestSCMHead" should hold the pertinent SCM information needed to build the the change and I don't see the title as part of that. For example, the title can change without the meaningful SCM information changing. Should the title be included in `equals()` comparisons? If the title changes, should a new build be triggered? I understand it would be convenient to have this information, and I even support the Title of Change requests being added to some shared interface. However, there needs to be some additional discussion of other possible places to add this information and possible effects and changes in behavior. I'm sorry. I want to support you in making improvements to this part of the API, but I'm have concerns about this improvement as it stands.

Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

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

[JIRA] (JENKINS-60103) Cannot send junit results to Octane

2019-11-08 Thread radislav.berkov...@hpe.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Radi Berkovich commented on  JENKINS-60103  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cannot send junit results to Octane   
 

  
 
 
 
 

 
 Hi do you have additional slaves? Is it occur with all slaves? is it occur with all jobs?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60110) Update AWS Java SDK

2019-11-08 Thread big...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Daniel V created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60110  
 
 
  Update AWS Java SDK   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Patrik Boström  
 
 
Components: 
 configuration-as-code-secret-ssm-plugin  
 
 
Created: 
 2019-11-08 15:53  
 
 
Environment: 
 Jenkins 2.190.2  configuration-as-code-secret-ssm:1.0.0  configuration-as-code:1.32  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Daniel V  
 

  
 
 
 
 

 
 AWS has recently released a feature to allow PODs in EKS/K8S to assume individual, fine grained roles. This allows certain pods to get IAM credentials to perform work in AWS. The blog post is here:   https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/   This requires an update to SDKs because the new SDKs slightly modify the DefaultCredential chain to also look for certain environment variables which point to files that contain enough data to convert the data to IAM credentials.   Currently, configuration-as-code-secret-ssm-plugin specifies it's aws-java-sdk as 1.11.341: https://github.com/jenkinsci/configuration-as-code-secret-ssm-plugin/blob/master/pom.xml#L43   The aforementioned feature requires 1.11.623, ref: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-minimum-sdk.html If we were to update this sdk, we could use this plugin in jenkins that's running in a K8S or EKS pod without further config.

[JIRA] (JENKINS-60097) Copying artifacts should offer to link them, if possible

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mikhail T edited a comment on  JENKINS-60097  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Copying artifacts should offer to link them, if possible   
 

  
 
 
 
 

 
 [~mindless], it seems like you are the maintainer of this plugin so I'm assigning the ticket to you.For some reason, the {{copyartifact-plugin}} component in Jira has no default assignee  – who'd normally be the ticket's author/maintainer . .. As a result there are multiple open tickets against the plugin, that remain unassigned (and, consequently, unattended).  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60097) Copying artifacts should offer to link them, if possible

2019-11-08 Thread mi+jenkins-2...@aldan.algebra.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mikhail T commented on  JENKINS-60097  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Copying artifacts should offer to link them, if possible   
 

  
 
 
 
 

 
 Alan Harder, it seems like you are the maintainer of this plugin so I'm assigning the ticket to you. For some reason, the copyartifact-plugin component in Jira has no default assignee – who'd normally be the ticket's author/maintainer. As a result there are multiple open tickets against the plugin, that remain unassigned (and, consequently, unattended).  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60097) Copying artifacts should offer to link them, if possible

2019-11-08 Thread mi+jenkins-2...@aldan.algebra.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mikhail T assigned an issue to Alan Harder  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60097  
 
 
  Copying artifacts should offer to link them, if possible   
 

  
 
 
 
 

 
Change By: 
 Mikhail T  
 
 
Assignee: 
 Alan Harder  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-45916) Path is not getting set correctly in pipeline when there is a variable present

2019-11-08 Thread daniel.soren...@clarivate.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Daniel Sorensen updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-45916  
 
 
  Path is not getting set correctly in pipeline when there is a variable present   
 

  
 
 
 
 

 
Change By: 
 Daniel Sorensen  
 

  
 
 
 
 

 
 After upgrading to latest Pipeline version and it's dependencies (we also upgraded the blue ocean plugins but don't think that caused an issue here), we noticed that the PATH was not getting set in our Jenkins Pipeline Jobs. After debugging found that if I set PATH to a string inside the "environment" section, as such: environment  {  {      PATH="/a/new/bin:$PATH"      } The PATH was updated successfully without any issues. However if I introduce a variable, the path does not get updated, and defaults to what is on the agent that runs the job. Example:pipeline  {  {    agent \ \ {  label 'docker'    }       environment {     PATH="/a/new/bin:${env.SCM_HOME}:$PATH"     SCM_HOME="${env.SCM_HOME}"    }   stages {     stage ('build') {   steps  {  {      echo "PATH=$PATH"       echo "SCM_HOME=$SCM_HOME"     }       }   } } OUTPUT:  {color:#9a}[Pipeline] {{color}{color:#9a}[Pipeline] withEnv{color}{color:#9a}[Pipeline] {{color}{color:#9a}[Pipeline] stage{color}{color:#9a}[Pipeline] { (build){color}{color:#9a}[Pipeline] echo{color}PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin{color:#9a}[Pipeline] echo{color}SCM_HOME=/usr/local/bin/scmtools/{color:#9a}[Pipeline] }{color}{color:#9a}[Pipeline] // stage{color}{color:#9a}[Pipeline] }{color}{color:#9a}[Pipeline] // withEnv{color}{color:#9a}[Pipeline] }{color}{color:#9a}[Pipeline] // node{color}{color:#9a}[Pipeline] End of Pipeline{color}Finished: SUCCESS   Notice that SCM_HOME resolves fine outside of PATH and that /a/new/bin was not added to the path. However if I drop the variable it will set PATH fine.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-45916) Path is not getting set correctly in pipeline when there is a variable present

2019-11-08 Thread daniel.soren...@clarivate.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Daniel Sorensen updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-45916  
 
 
  Path is not getting set correctly in pipeline when there is a variable present   
 

  
 
 
 
 

 
Change By: 
 Daniel Sorensen  
 

  
 
 
 
 

 
 After upgrading to latest Pipeline version and it's dependencies (we also upgraded the blue ocean plugins but don't think that caused an issue here), we noticed that the PATH was not getting set in our Jenkins Pipeline Jobs. After debugging found that if I set PATH to a string inside the "environment" section, as such: environment  \ {     PATH="/a/new/bin:$PATH"    } The PATH was updated successfully without any issues. However if I introduce a variable, the path does not get updated, and defaults to what is on the agent that runs the job. Example:pipeline  \ {   agent \{  label 'docker'    }     environment  \ {     PATH="/a/new/bin:$ \ {env.SCM_HOME}:$PATH"     SCM_HOME="$ \ {env.SCM_HOME}"    }   stages  \ {     stage ('build')  \ {   steps  \ {     echo "PATH=$PATH"     echo "SCM_HOME=$SCM_HOME"   }     }   } } OUTPUT:  {color:#9a}[Pipeline]  \ {{color}{color:#9a}[Pipeline] withEnv{color}{color:#9a}[Pipeline]  \ {{color}{color:#9a}[Pipeline] stage{color}{color:#9a}[Pipeline]  \ { (build){color}{color:#9a}[Pipeline] echo{color}PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin{color:#9a}[Pipeline] echo{color}SCM_HOME=/usr/local/bin/scmtools/{color:#9a}[Pipeline] }{color}{color:#9a}[Pipeline] // stage{color}{color:#9a}[Pipeline] }{color}{color:#9a}[Pipeline] // withEnv{color}{color:#9a}[Pipeline] }{color}{color:#9a}[Pipeline] // node{color}{color:#9a}[Pipeline] End of Pipeline{color}Finished: SUCCESS   Notice that SCM_HOME resolves fine outside of PATH and that /a/new/bin was not added to the path. However if I drop the variable it will set PATH fine.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes

Title: Message Title


 
 
 
 

 
 
 

 
   
 Thomas de Grenier de Latour edited a comment on  JENKINS-43889  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: ssh-agent-plugin leaking some ssh-agent processes   
 

  
 
 
 
 

 
 I had kind of forgotten about this issue, because we've been using a {{RunListener}} to work around it, similar to the one I had attached already, but if anyone is interested, the report is still relevant (just checked with ssh-agent plugin code from master, and Jenkins 2.190.2).Here is a failing test case one can try, to be added in {{SSHAgentBuildWrapperTest}}:{code:java}@Issue("JENKINS-43889")@Testpublic void sshAgentStoppedOnEarlyBuildFailure() throws Exception {List credentialIds = new ArrayList();credentialIds.add(CREDENTIAL_ID);SSHUserPrivateKey key = new BasicSSHUserPrivateKey(CredentialsScope.GLOBAL, credentialIds.get(0), "cloudbees",new BasicSSHUserPrivateKey.DirectEntryPrivateKeySource(getPrivateKey()), "cloudbees", "test");SystemCredentialsProvider.getInstance().getCredentials().add(key);SystemCredentialsProvider.getInstance().save();FreeStyleProject job = r.createFreeStyleProject("I_will_die_during_SCM_checkout");job.setAssignedNode(r.createSlave());SSHAgentBuildWrapper sshAgent = new SSHAgentBuildWrapper(credentialIds, false);job.getBuildWrappersList().add(sshAgent);// make sure this job fails during SCM checkoutjob.setScm(new FailingSCM());Future build = job.scheduleBuild2(0);r.assertBuildStatus(Result.FAILURE, build);r.assertLogContains(Messages.SSHAgentBuildWrapper_Started(), build.get());r.assertLogContains(Messages.SSHAgentBuildWrapper_Stopped(), build.get());}static class FailingSCM extends SCM {@Overridepublic ChangeLogParser createChangeLogParser() {return null;}// default implementation of checkout(...) method will fail, that's what we want} {code} (you will then have come `ssh-agent` processes to kill after running this test) {code} I'm still not sure where this should get fixed:- either in core, by moving the {{Environment.tearDown}} calls up from {{BuildExecution.doRun}} to {{AbstractBuildExecution.run}}- or in the ssh-agent plugin itself, if what it does (ie., adding an {{Environment}} to the build from its {{BuildWrapper.preCheckout}} implementation, rather than from {{BuildWrapper.setUp}}, so that its already set up during SCM checkout) is really bad/unsupported    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes

Title: Message Title


 
 
 
 

 
 
 

 
   
 Thomas de Grenier de Latour commented on  JENKINS-43889  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: ssh-agent-plugin leaking some ssh-agent processes   
 

  
 
 
 
 

 
 To be extra clear in my explanations, here is how the ssh-agent gets launched, starting from AbstractBuild.AbstractBuildExecution#run: 
 
AbstractBuild.AbstractBuildExecution#run(...) - AbstractBuild.java#L498 
SCMCheckoutStrategy#preCheckout(...) - SCMCheckoutStrategy.java#L76 
SSHAgentBuildWrapper#preCheckout(...) - SSHAgentBuildWrapper.java#L228 
SSHAgentBuildWrapper#createSSHAgentEnvironment(...) - SSHAgentBuildWrapper.java#L248 
SSHAgentBuildWrapper.SSHAgentEnvironment#SSHAgentEnvironment(...) - SSHAgentBuildWrapper.java#L363 
 And here is how it gets stopped (when it does), again starting from AbstractBuild.AbstractBuildExecution#run (a few lines below): 
 
AbstractBuild.AbstractBuildExecution#run(...) - AbstractBuild.java#L504 
Build#doRun(...) - Build.java#L174 
SSHAgentBuildWrapper.SSHAgentEnvironment#tearDown(...) - SSHAgentBuildWrapper.java#L417 
  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[JIRA] (JENKINS-60108) Severity Distribution table - missing data

2019-11-08 Thread frantisek.sichin...@gopay.cz (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 František Sichinger updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60108  
 
 
  Severity Distribution table - missing data   
 

  
 
 
 
 

 
Change By: 
 František Sichinger  
 
 
Priority: 
 Minor Major  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60109) After 2.0.0 trending graph is no longer intractable

2019-11-08 Thread frantisek.sichin...@gopay.cz (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 František Sichinger created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60109  
 
 
  After 2.0.0 trending graph is no longer intractable   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 image-2019-11-08-15-39-41-805.png  
 
 
Components: 
 dependency-check-jenkins-plugin  
 
 
Created: 
 2019-11-08 14:44  
 
 
Environment: 
 Java 1.8  Jenkins version 2.203  dependency check plugin version: 2.1.0  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 František Sichinger  
 

  
 
 
 
 

 
 Before version 2.0.0 user could interact with the  plugin's vulnerability trending graph, .  I could click on any build number in the graph, and browser would be redirected to appropriate build in history.  This seems to be no longer possible after 2.0.0. Currently the only action I'm able to do, is to toggle visibility one of horizontal lines by clicking on the labels below.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60053) Create null diff file on config history

2019-11-08 Thread brain...@yandex.ru (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Alexander Moiseenko commented on  JENKINS-60053  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Create null diff file on config history   
 

  
 
 
 
 

 
 Possibly duplicates JENKINS-57837  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-43889) ssh-agent-plugin leaking some ssh-agent processes

2019-11-08 Thread mi+jenkins-2...@aldan.algebra.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Thomas de Grenier de Latour commented on  JENKINS-43889  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: ssh-agent-plugin leaking some ssh-agent processes   
 

  
 
 
 
 

 
 I had kind of forgotten about this issue, because we've been using a RunListener to work around it, similar to the one I had attached already, but if anyone is interested, the report is still relevant (just checked with ssh-agent plugin code from master, and Jenkins 2.190.2). Here is a failing test case one can try, to be added in SSHAgentBuildWrapperTest: 

 

@Issue("JENKINS-43889")
@Test
public void sshAgentStoppedOnEarlyBuildFailure() throws Exception {
List credentialIds = new ArrayList();
credentialIds.add(CREDENTIAL_ID);

SSHUserPrivateKey key = new BasicSSHUserPrivateKey(CredentialsScope.GLOBAL, credentialIds.get(0), "cloudbees",
new BasicSSHUserPrivateKey.DirectEntryPrivateKeySource(getPrivateKey()), "cloudbees", "test");
SystemCredentialsProvider.getInstance().getCredentials().add(key);
SystemCredentialsProvider.getInstance().save();

FreeStyleProject job = r.createFreeStyleProject("I_will_die_during_SCM_checkout");
job.setAssignedNode(r.createSlave());

SSHAgentBuildWrapper sshAgent = new SSHAgentBuildWrapper(credentialIds, false);
job.getBuildWrappersList().add(sshAgent);

// make sure this job fails during SCM checkout
job.setScm(new FailingSCM());

Futureextends FreeStyleBuild> build = job.scheduleBuild2(0);
r.assertBuildStatus(Result.FAILURE, build);
r.assertLogContains(Messages.SSHAgentBuildWrapper_Started(), build.get());
r.assertLogContains(Messages.SSHAgentBuildWrapper_Stopped(), build.get());
}

static class FailingSCM extends SCM {
@Override
public ChangeLogParser createChangeLogParser() {
return null;
}
// default implementation of checkout(...) method will fail, that's what we want
}

(you will then have come `ssh-agent` processes to kill after running this test)

 

 I'm still not sure where this should get fixed: 
 
either in core, by moving the Environment.tearDown calls up from BuildExecution.doRun to AbstractBuildExecution.run 
or in the ssh-agent plugin itself, if what it does (ie., adding an Environment to the build from its BuildWrapper.preCheckout implementation, rather than from BuildWrapper.setUp, so that its already set up during SCM checkout) is really bad/unsupported

[JIRA] (JENKINS-60074) Empty array returned with p4sync after 1.10.6

2019-11-08 Thread pal...@perforce.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Paul Allen commented on  JENKINS-60074  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Empty array returned with p4sync after 1.10.6   
 

  
 
 
 
 

 
 Passes internal tests - pushed to master It may fail CI builds as Jenkins infra has been a bit sensitive lately. https://ci.jenkins.io/job/Plugins/job/p4-plugin/job/master/409/  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60074) Empty array returned with p4sync after 1.10.6

2019-11-08 Thread pal...@perforce.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Paul Allen started work on  JENKINS-60074  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
Change By: 
 Paul Allen  
 
 
Status: 
 Open In Progress  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60074) Empty array returned with p4sync after 1.10.6

2019-11-08 Thread pal...@perforce.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Paul Allen updated  JENKINS-60074  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60074  
 
 
  Empty array returned with p4sync after 1.10.6   
 

  
 
 
 
 

 
Change By: 
 Paul Allen  
 
 
Status: 
 In  Progress  Review  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60097) Copying artifacts should offer to link them, if possible

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mikhail T updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60097  
 
 
  Copying artifacts should offer to link them, if possible   
 

  
 
 
 
 

 
Change By: 
 Mikhail T  
 

  
 
 
 
 

 
 I have several C++ projects, that all depend on Boost – which we build locally on the same Jenkins.The depending projects are configured to copy artifacts from the last successful build of Boost, which works. But the number of files installed by Boost (libraries and headers) is over 14K, which takes  multiple minutes to copy over even on the same server. For example,  not  note  the four minutes it took in the most recent case – artifact copying is the next step after untarring in this build:{noformat} ... 19:08:14 Untarring QuantLib-1.16.tar.gz to ...19:08:19 Untar completed.19:12:10 Copied 14,120 artifacts from "Boost » Compile" build number 35 ...  {noformat}I'd like to propose  the  an  option to , instead of copying them,  _symlink_ to the chosen build's artifacts from the workspace, if possible (if the build was on the same agent). This would save both time and space in many cases.(Note, that symbolic links are available on Windows too nowadays.)  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[JIRA] (JENKINS-60108) Severity Distribution table - missing data

2019-11-08 Thread frantisek.sichin...@gopay.cz (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 František Sichinger updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60108  
 
 
  Severity Distribution table - missing data   
 

  
 
 
 
 

 
Change By: 
 František Sichinger  
 

  
 
 
 
 

 
 Please check out the attached file.The summary displays only 1 record - the beanutils library.But according to report, which was produced by the maven plugin during build, there should be exactly 5 records in the table.  Also notice that the menu on the left ,  where is  contains  the button "Dependency-Check"  displayed    three times.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60108) Severity Distribution table - missing data

2019-11-08 Thread frantisek.sichin...@gopay.cz (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 František Sichinger updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60108  
 
 
  Severity Distribution table - missing data   
 

  
 
 
 
 

 
Change By: 
 František Sichinger  
 

  
 
 
 
 

 
 Please check out the attached file. The summary displays only 1 record - the beanutils library. But according to report, which was produced by the maven plugin during build, there should be exactly 5 records in the table. Also notice that the menu on the left,  where is the button "Dependency-Check" displayed three times.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60108) Severity Distribution table - missing data

2019-11-08 Thread frantisek.sichin...@gopay.cz (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 František Sichinger created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60108  
 
 
  Severity Distribution table - missing data   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 image-2019-11-08-15-04-29-456.png  
 
 
Components: 
 dependency-check-jenkins-plugin  
 
 
Created: 
 2019-11-08 14:12  
 
 
Environment: 
 Java 1.8  Jenkins version 2.203  dependency check plugin version: 2.1.0  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 František Sichinger  
 

  
 
 
 
 

 
 Please check out the attached file.  The summary displays only 1 record - the beanutils library.  But according to report, which was produced by the maven plugin during build, there should be exactly 5 records in the table.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-50191) Multibranch Pipeline tends to keep rebuilding same commits

2019-11-08 Thread jimkli...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jim Klimov commented on  JENKINS-50191  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Multibranch Pipeline tends to keep rebuilding same commits   
 

  
 
 
 
 

 
 For the bit about PR-merge builds, yes this is expected to re-run (once per seen target branch update though!) and part of the design idea about such ephemeral merge branches.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-59793) Possible thread leak 'QueueSubTaskMetrics' in metrics

2019-11-08 Thread manuelramonleonjime...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ramon Leon commented on  JENKINS-59793  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Possible thread leak 'QueueSubTaskMetrics' in metrics   
 

  
 
 
 
 

 
 I mentioned this because in the instance we detected the metric threads, there were a lot of log messages of this type. But maybe it's not related and it's just a performance issue.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60107) durabletask v1.33 - process apparently never started in /var/lib/jenkins/workspace/local-cloud-regression-test@tmp/durable-fa896164

2019-11-08 Thread jonud...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jon Udaondo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60107  
 
 
  durabletask v1.33 - process apparently never started in /var/lib/jenkins/workspace/local-cloud-regression-test@tmp/durable-fa896164   
 

  
 
 
 
 

 
Change By: 
 Jon Udaondo  
 
 
Summary: 
 durabletask v1.33 - process apparently never started in /var/lib/jenkins/workspace/local-cloud-regression-test@tmp/durable-fa896164  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60107) process apparently never started in /var/lib/jenkins/workspace/local-cloud-regression-test@tmp/durable-fa896164

2019-11-08 Thread jonud...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jon Udaondo assigned an issue to Carroll Chiou  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60107  
 
 
  process apparently never started in /var/lib/jenkins/workspace/local-cloud-regression-test@tmp/durable-fa896164   
 

  
 
 
 
 

 
Change By: 
 Jon Udaondo  
 
 
Assignee: 
 Carroll Chiou  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60107) process apparently never started in /var/lib/jenkins/workspace/local-cloud-regression-test@tmp/durable-fa896164

2019-11-08 Thread jonud...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jon Udaondo created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60107  
 
 
  process apparently never started in /var/lib/jenkins/workspace/local-cloud-regression-test@tmp/durable-fa896164   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 image-2019-11-08-14-16-55-929.png, image-2019-11-08-14-17-40-455.png, image-2019-11-08-14-18-42-774.png, image-2019-11-08-14-19-32-129.png  
 
 
Components: 
 durable-task-plugin  
 
 
Created: 
 2019-11-08 13:20  
 
 
Environment: 
 jenkins: v2.190.2  durable-task: v1.33  
 
 
Labels: 
 jenkins pipeline plugin  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Jon Udaondo  
 

  
 
 
 
 

 
 As mentioned in this bug I wrote some days ago: https://issues.jenkins-ci.org/browse/JENKINS-59838   I have updated Durable Task Plugin to v1.33 but I am still facing the same issue.  I have captured the logs on "System Log"  The output I get from that log does mean to much to me:    Here the error appeared on the job console:    And the "system log" changed to:      This is being a great headache because I always get that error.

[JIRA] (JENKINS-59793) Possible thread leak 'QueueSubTaskMetrics' in metrics

2019-11-08 Thread jgl...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jesse Glick commented on  JENKINS-59793  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Possible thread leak 'QueueSubTaskMetrics' in metrics   
 

  
 
 
 
 

 
 I do not believe the workflow-cps code mentioned has any relation to this issue. Perhaps I am missing something.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60016) docker.stop() pipeline step no longer works for windows

2019-11-08 Thread dylan.yatigamm...@hitachivantara.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Yatigammana commented on  JENKINS-60016  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: docker.stop() pipeline step no longer works for windows   
 

  
 
 
 
 

 
 for anyone else with this issue, my workaround is to make sure I give the container a name, then manually run bat script to stop the container by name. e.g (something along these lines) 

 

String containerName = "containerName"

//start container with containerName
def compileContainer = docker.image("dockerImageName").run("--name ${containerName}", "ping -t localhost")

//stop & rm container with containerName
bat(script: "docker stop ${containerName}")
bat(script: "docker rm -f ${containerName}")
 

  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60087) Kubernetes nodes failed not removed

2019-11-08 Thread jenkins-ci....@meneguello.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Bruno Meneguello updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60087  
 
 
  Kubernetes nodes failed not removed   
 

  
 
 
 
 

 
Change By: 
 Bruno Meneguello  
 

  
 
 
 
 

 
 When my pods are killed by OOM, the nodes aren't removed, this pollutes the interface and causes the job stay running but zombie.!image-2019-11-07-12-18-14-069.png! If I click to abort the job it prints "Are you sure you want to abort null?" !image-2019-11-07-12-07-52-341.png!  And on This message come from [executors.jelly|https://github.com/jenkinsci/jenkins/blob/0af98fe7163a821710f8be0dbc11086d4acd8bf2/core/src/main/resources/lib/hudson/executors.jelly#L113] when {{executor.currentExecutable.fullDisplayName}} is {{null.}}On  proceed it deletes the node, as expected.In the logs I found these entries:{code:java}INFO o.c.j.p.k.pod.retention.Reaper#eventReceived: default/infra-mf3jg was just deleted, so removing corresponding Jenkins agentINFO j.s.DefaultJnlpSlaveReceiver#channelClosed: IOHub#1: Worker[channel:java.nio.channels.SocketChannel[connected local=/172.17.0.2:5 remote=ip-172-16-29-221.ec2.internal/172.16.29.221:39454]] / Computer.threadPoolForRemoting [#12347] for infra-mf3jg terminated: java.nio.channels.ClosedChannelException{code}I think it's related to Reaper class, when DELETED event is received ([here|https://github.com/jenkinsci/kubernetes-plugin/blob/5ce0693a00699fec026acfd8952f98d4bd8ac309/src/main/java/org/csanchez/jenkins/plugins/kubernetes/pod/retention/Reaper.java#L122]) which calls [Node#removeNode| [https://github.com/jenkinsci/jenkins/blob/41a13dffc612ca3b5c48ab3710500562a3b40bf7/core/src/main/java/jenkins/model/Nodes.java #L270].] There I found this comment "If the node instance is not in the list of nodes, then this will be a no-op, even if there is another instance with the same".I think by some reason the instance passed by Reaper is different from Node, which causes it to be ignored.The OfflineCause for the node is "Node is being removed"!image-2019-11-07-12-15-35-071.png!  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60090) Job builds tags even though there is no change in Bitbucket

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60090  
 
 
  Job builds tags even though there is no change in Bitbucket   
 

  
 
 
 
 

 
Change By: 
 Mark Waite  
 
 
Summary: 
 Job  Triggered  builds tags  even though there is no change in Bitbucket
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60090) Job Triggered even though there is no change in Bitbucket

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite resolved as Not A Defect  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Resolving this as "Not a defect" because it is how the plugin is intended to work.  
 

  
 
 
 
 

 
 Jenkins /  JENKINS-60090  
 
 
  Job Triggered even though there is no change in Bitbucket
 

  
 
 
 
 

 
Change By: 
 Mark Waite  
 
 
Status: 
 Open Resolved  
 
 
Resolution: 
 Not A Defect  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To vie

[JIRA] (JENKINS-60090) Job Triggered even though there is no change in Bitbucket

2019-11-08 Thread dylan.yatigamm...@hitachivantara.com (JIRA)

Title: Message Title

Mark Waite commented on JENKINS-60090

Re: Job Triggered even though there is no change in Bitbucket

I suspect you are relying on the JENKINS-19022 bug which causes build history from earlier builds to be incorrectly included in later build records. The git plugin does not have a concept of the "age" of a tag or of the "create date" of a tag. The git plugin has a concept that a SHA1 has already been built or has not already been built. In your case, my guess would be that the SHA-1 hashes from the very old builds had been copied into later build records due to JENKINS-19022. A further guess is that the build records which contained those old records have now expired off the end of the list. If my theory is correct, then you should be able to prevent future rebuilds of old tags by retaining all history for that job.

Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

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

[JIRA] (JENKINS-60016) docker.stop() pipeline step no longer works for windows

Title: Message Title


 
 
 
 

 
 
 

 
   
 Dylan Yatigammana commented on  JENKINS-60016  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: docker.stop() pipeline step no longer works for windows   
 

  
 
 
 
 

 
 I have confirmed that the container id has become the entire run command, by manually executing the bat command 

 

docker stop ${container.id}
 

  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60103) Cannot send junit results to Octane

2019-11-08 Thread marianarcisa.ga...@microfocus.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Maria Narcisa Galan assigned an issue to Radi Berkovich  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60103  
 
 
  Cannot send junit results to Octane   
 

  
 
 
 
 

 
Change By: 
 Maria Narcisa Galan  
 
 
Assignee: 
 Maria Narcisa Galan Radi Berkovich  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60106) My views 'new view' links to not authorized top 'new view' editor

2019-11-08 Thread thorin...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ricardo Santos created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60106  
 
 
  My views 'new view' links to not authorized top 'new view' editor   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 image-2019-11-08-11-48-08-257.png, image-2019-11-08-11-48-54-312.png  
 
 
Components: 
 core  
 
 
Created: 
 2019-11-08 11:54  
 
 
Environment: 
 Jenkins: 2.190.2/2.203 (pristine), Browser: Firefox/Chrome, OS: All  
 
 
Labels: 
 views  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Ricardo Santos  
 

  
 
 
 
 

 
 When logged in as a user without View -> Create permissions, when on the "My Views" page, the "New View" link becomes visible. Since the user doesn't have permissions to create views on the top level (global views): 
 
I would expect this link to point to "/user/[username]/my-views/newView" instead of "/newView". 
Or for it to be hidden. 
 Screenshots of a pristine Jenkins docker container with Legacy Authorization Mode:

[JIRA] (JENKINS-60105) Kubernetes plugin fails with EKS

2019-11-08 Thread jnieb...@cfire.de (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jochen Niebuhr updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60105  
 
 
  Kubernetes plugin fails with EKS   
 

  
 
 
 
 

 
Change By: 
 Jochen Niebuhr  
 

  
 
 
 
 

 
 I'm using a Jenkins installation which is run on a standard ec2 instance. This Jenkins instance is supposed to connect to an EKS cluster. EKS cluster auth is done via aws-iam-authenticator which is correctly configured on the machine. I've put all the config in the .kube/config for the jenkins user. The kubernetes plugin will pick up the k8s config just fine and succeed through all connection tests. It will also run builds just fine for about 15 minutes. At that point, the token issues from aws iam authenticator will be expired and no more pods can be created for my builds. Configuration tests do still work after that, so I guess the plugin creates a new client for those.The plugin will print the following error message:  {code :java } 2019-11-08 11:32:50.552+ [id=24] WARNING o.c.j.p.k.KubernetesCloud#provision: Failed to count the # of live instances on Kubernetes2019-11-08 11:32:50.552+ [id=24] WARNING o.c.j.p.k.KubernetesCloud#provision: Failed to count the # of live instances on Kubernetesio.fabric8.kubernetes.client.KubernetesClientException: Failure executing: GET at: [https:// 296cb72614fca8d61a1b611020af335c . yl4 . .. eu-west-1.eks.amazonaws.com/api/v1/namespaces/jenkins/pods?labelSelector=app.kubernetes.io%2Fpart-of%3Djenkins%2Capp.kubernetes.io%2Fcomponent%3Dslave]. Message: Unauthorized! Token may have expired! Please log-in again. Unauthorized. at io.fabric8.kubernetes.client.dsl.base.OperationSupport.requestFailure(OperationSupport.java:510) at io.fabric8.kubernetes.client.dsl.base.OperationSupport.assertResponseCode(OperationSupport.java:447) at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:413) at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:372) at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:354) at io.fabric8.kubernetes.client.dsl.base.BaseOperation.listRequestHelper(BaseOperation.java:153) at io.fabric8.kubernetes.client.dsl.base.BaseOperation.list(BaseOperation.java:620) at io.fabric8.kubernetes.client.dsl.base.BaseOperation.list(BaseOperation.java:69) at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.getActiveSlavePods(KubernetesCloud.java:615) at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.addProvisionedSlave(KubernetesCloud.java:590) at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.provision(KubernetesCloud.java:542) at hudson.slaves.NodeProvisioner$StandardStrategyImpl.apply(NodeProvisioner.java:729) at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:332) at hudson.slaves.NodeProvisioner.access$900(NodeProvisioner.java:63) at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:823) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:72) at jenkins.security.ImpersonatingScheduledExecutorService$1.run(ImpersonatingSched

[JIRA] (JENKINS-60105) Kubernetes plugin fails with EKS

2019-11-08 Thread jnieb...@cfire.de (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jochen Niebuhr updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60105  
 
 
  Kubernetes plugin fails with EKS   
 

  
 
 
 
 

 
Change By: 
 Jochen Niebuhr  
 

  
 
 
 
 

 
 I'm using a Jenkins installation which is run on a standard ec2 instance. This Jenkins instance is supposed to connect to an EKS cluster. EKS cluster auth is done via aws-iam-authenticator which is correctly configured on the machine. I've put all the config in the .kube/config for the jenkins user.The kubernetes plugin will pick up the k8s config just fine and succeed through all connection tests. It will also run builds just fine for about 15 minutes. At that point, the token issues from aws iam authenticator will be expired and no more pods can be created for my builds. Configuration tests do still work after that, so I guess the plugin creates a new client for those.The plugin will print the following error message: ``` {code} 2019-11-08 11:32:50.552+ [id=24] WARNING o.c.j.p.k.KubernetesCloud#provision: Failed to count the # of live instances on Kubernetes2019-11-08 11:32:50.552+ [id=24] WARNING o.c.j.p.k.KubernetesCloud#provision: Failed to count the # of live instances on Kubernetesio.fabric8.kubernetes.client.KubernetesClientException: Failure executing: GET at:  [  https://296cb72614fca8d61a1b611020af335c.yl4.eu-west-1.eks.amazonaws.com/api/v1/namespaces/jenkins/pods?labelSelector=app.kubernetes.io%2Fpart-of%3Djenkins%2Capp.kubernetes.io%2Fcomponent%3Dslave ] . Message: Unauthorized! Token may have expired! Please log-in again. Unauthorized. at io.fabric8.kubernetes.client.dsl.base.OperationSupport.requestFailure(OperationSupport.java:510) at io.fabric8.kubernetes.client.dsl.base.OperationSupport.assertResponseCode(OperationSupport.java:447) at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:413) at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:372) at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:354) at io.fabric8.kubernetes.client.dsl.base.BaseOperation.listRequestHelper(BaseOperation.java:153) at io.fabric8.kubernetes.client.dsl.base.BaseOperation.list(BaseOperation.java:620) at io.fabric8.kubernetes.client.dsl.base.BaseOperation.list(BaseOperation.java:69) at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.getActiveSlavePods(KubernetesCloud.java:615) at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.addProvisionedSlave(KubernetesCloud.java:590) at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.provision(KubernetesCloud.java:542) at hudson.slaves.NodeProvisioner$StandardStrategyImpl.apply(NodeProvisioner.java:729) at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:332) at hudson.slaves.NodeProvisioner.access$900(NodeProvisioner.java:63) at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:823) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:72) at jenkins.security.ImpersonatingScheduledExecutorService$1.run(ImpersonatingScheduledExec

[JIRA] (JENKINS-60105) Kubernetes plugin fails with EKS

2019-11-08 Thread jnieb...@cfire.de (JIRA)

Title: Message Title

Jochen Niebuhr created an issue

Jenkins / JENKINS-60105

Kubernetes plugin fails with EKS

Issue Type:
Bug

Assignee:
Unassigned

Components:
kubernetes-plugin

Created:
2019-11-08 11:43

Priority:
Minor

Reporter:
Jochen Niebuhr

I'm using a Jenkins installation which is run on a standard ec2 instance. This Jenkins instance is supposed to connect to an EKS cluster. EKS cluster auth is done via aws-iam-authenticator which is correctly configured on the machine. I've put all the config in the .kube/config for the jenkins user. The kubernetes plugin will pick up the k8s config just fine and succeed through all connection tests. It will also run builds just fine for about 15 minutes. At that point, the token issues from aws iam authenticator will be expired and no more pods can be created for my builds. Configuration tests do still work after that, so I guess the plugin creates a new client for those. The plugin will print the following error message: ``` 2019-11-08 11:32:50.552+ [id=24] WARNING o.c.j.p.k.KubernetesCloud#provision: Failed to count the # of live instances on Kubernetes2019-11-08 11:32:50.552+ [id=24] WARNING o.c.j.p.k.KubernetesCloud#provision: Failed to count the # of live instances on Kubernetesio.fabric8.kubernetes.client.KubernetesClientException: Failure executing: GET at: https://296cb72614fca8d61a1b611020af335c.yl4.eu-west-1.eks.amazonaws.com/api/v1/namespaces/jenkins/pods?labelSelector=app.kubernetes.io%2Fpart-of%3Djenkins%2Capp.kubernetes.io%2Fcomponent%3Dslave. Message: Unauthorized! Token may have expired! Please log-in again. Unauthorized. at io.fabric8.kubernetes.client.dsl.base.OperationSupport.requestFailure(OperationSupport.java:510) at io.fabric8.kubernetes.client.dsl.base.OperationSupport.assertResponseCode(OperationSupport.java:447) at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:413) at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport

[JIRA] (JENKINS-59508) sidebar link names are not truncated causing funky rendering

2019-11-08 Thread fqueir...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Félix Queiruga Balado assigned an issue to Félix Queiruga Balado  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-59508  
 
 
  sidebar link names are not truncated causing funky rendering   
 

  
 
 
 
 

 
Change By: 
 Félix Queiruga Balado  
 
 
Assignee: 
 Félix Queiruga Balado  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60104) Agent to Master Access Control rule throws java exception

2019-11-08 Thread dgal...@gmail.com (JIRA)

Title: Message Title

Daniel Galvao created an issue

Jenkins / JENKINS-60104

Agent to Master Access Control rule throws java exception

Issue Type:
Bug

Assignee:
Unassigned

Components:
core

Created:
2019-11-08 11:34

Environment:
Jenkins 2.203 java version "1.8.0_201" Java(TM) SE Runtime Environment (build 1.8.0_201-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode) Ubuntu 18.04.3 LTS

Priority:
Minor

Reporter:
Daniel Galvao

I've run jenkins on a single master for sometime and recently added the first jenkins agent. I'm trying to setup the agent-master access control (manage jenkins -> configure global security -> Agent Master Security Rules can be tweaked here , url: https:///administrativeMonitor/slaveToMasterAccessControl/rule/ ) I try to add a file access rule because I use the SSH publisher and the agent needs to access an SSH key in the master. When I click the "Update" button I get the java exception below. Even if I make no changes to that page and click the button I get the same exception. Please advise. Thank you! A problem occurred while processing the request. Please check our bug tracker to see if a similar problem has already been reported. If it is already reported, please vote and put a comment on it to let us gauge the impact of the problem. If you think this is a new issue, please file a new issue. When you file an issue, make sure to add the entire stack trace, along with the version of Jenkins and relevant plugins. The users list might be also useful in understanding what has happened. Stack trace java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:237) at java.lang.StringBuilder.charAt(StringBuilder.java:76) at jenkins.security.s2m.Adm

[JIRA] (JENKINS-59259) sshAgent step does not survive agent disconnect/reconnect

2019-11-08 Thread jon.s...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jon Sten updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-59259  
 
 
  sshAgent step does not survive agent disconnect/reconnect   
 

  
 
 
 
 

 
Change By: 
 Jon Sten  
 

  
 
 
 
 

 
 The following pipeline code fails if the connection to the agent is lost and reconnected during execution of the shell script:{code :groovy }node {sshagent([' db1284e3-6df6-4c4f-91dc-d2648957cd3c someCredential ']) {sh '''for i in `seq 1 120`;dosleep 1echo $idone'''echo "Done"}echo "Done"}{code}The build log is as follows:  {noformat}Started by user JonRunning in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on build-srv123 in /some/path/workspace/job/path[Pipeline] {[Pipeline] sshagent[ssh-agent] Using credentials  svcjenkins  someCredential [ssh-agent] Looking for ssh-agent implementation...[ssh-agent]   Exec ssh-agent (binary ssh-agent on a remote machine)$ ssh-agentSSH_AUTH_SOCK=/tmp/ssh-gDb94Onc5Loa/agent.30438SSH_AGENT_PID=30440Running ssh-add (command line suppressed)Identity added: /some/path/workspace/job/path-tmp/private_key_970164985924018321.key (/some/path/workspace/job/path-tmp/private_key_970164985924018321.key)[ssh-agent] Started.[Pipeline] {[Pipeline] sh+ seq 1 120+ sleep 1+ echo 11+ sleep 1+ echo 22+ sleep 1+ echo 33+ sleep 1+ echo 44+ sleep 1+ echo 55+ sleep 1Cannot contact build-srv123: hudson.remoting.ChannelClosedException: Channel "unknown": Remote call on build-srv123 failed. The channel is closing down or has closed down+ echo 66+ sleep 1+ echo 77+ sleep 1+ echo 88... truncated for your reading sanity...+ sleep 1+ echo 119119+ sleep 1+ echo 120120[Pipeline] echoDone[Pipeline] }[Pipeline] // sshagent[Pipeline] }[Pipeline] // node[Pipeline] End of Pipeline[BFA] Scanning build for known causes...[BFA] No failure causes found[BFA] Done. 0sjava.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2681) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:3156) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:862) at java.io.ObjectInputStream.(ObjectInputStream.java:358) at hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:49) at hudson.remoting.Command.readFrom(Command.java:140) at hudson.remoting.Command.readFrom(Command.java:126) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:36) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:63)Caused: java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:77)Caused: hudson.remoting.ChannelClosedException: Channel "unknown": Remote call on build-srv123 failed. The channel is closing down or has closed down at hudson.remoting.Channel.call(Channel.java:950) at hudson.Launcher$RemoteLauncher.launch(Launcher.java:1060) at hudson.Launcher$ProcStarter.start(Launcher.java:455) at com.cloudbees.jenkins.p

[JIRA] (JENKINS-60102) Getting "unexpected modal dialog" exception

Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Latombe edited a comment on  JENKINS-60102  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Getting "unexpected modal dialog" exception   
 

  
 
 
 
 

 
 [~olivergondza] It's a test from a CloudBees test harness so I can't share it directly, but I believe the cause is that the alert is already displayed when you are attempting  to capture  the window handle. I have provided a PR that should fix it.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60102) Getting "unexpected modal dialog" exception

Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Latombe commented on  JENKINS-60102  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Getting "unexpected modal dialog" exception   
 

  
 
 
 
 

 
 Oliver Gondža It's a test from a CloudBees test harness so I can't share it directly, but I believe the cause is that the alert is already displayed when you are attempting the window handle. I have provided a PR that should fix it.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-33487) Team Foundation Server plugin error about already mapped folder after updating to 4.1.0

2019-11-08 Thread tomeks...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tomek Swiecicki commented on  JENKINS-33487  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Team Foundation Server plugin error about already mapped folder after updating to 4.1.0   
 

  
 
 
 
 

 
 I am not sure this is related. I noticed that the plugin creates TFS workspace using the same TFS name but mapped to foldername and foldername@script depending of the step. By next step it detects the workspace is not mapped correctly local folder it deletes the tfs workspace and recreates it with a different local path. The build successful at the end, but it takes a long time to download the whole project twice. Why does it need to check-out 1627 resources just to read Jenkinsfile? Branch indexing Checking out hudson.plugins.tfs.TeamFoundationServerScm into c:\temp\workspace\xxx_Development@script to read Jenkinsfile Querying for remote changeset at '$/r/Development' as of 'D2019-11-08T09:10:18Z'... Query result is: Changeset #35974 by '' on '2019-11-07T19:34:04Z'. Checking if there exists a mapping for c:\temp\workspace\x_Development@script...no. Downloading list of workspaces from  x xxx ... Creating workspace 'Hudson-Development-MASTER' owned by 'xx'... Mapping '$/xxx/Development' to local folder 'c:\temp\workspace\x_Development@script' in workspace 'Hudson-Development-MASTER'... Created workspace 'Hudson-Development-MASTER'. Getting version 'C35974' to 'c:\temp\xxx_Development@script'... Finished getting version 'C35974'. Retrieved 1627 resources.Running in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on Jenkins in c:\temp\workspace\xx2_Development[Pipeline] {[Pipeline] stage[Pipeline] { (Declarative: Checkout SCM)[Pipeline] checkoutQuerying for remote changeset at '$/x/Development' as of 'D2019-11-08T09:10:18Z'... Query result is: Changeset #35974 by 'x' on '2019-11-07T19:34:04Z'. Checking if there exists a mapping for c:\temp\workspace\x_Development...no. Downloading list of workspaces from  Warning: Although the server thinks the workspace exists, no mapping was found. Warning: The local folder is missing. Deleting workspaces named 'Hudson-Development-MASTER' from computer ''... Deleted 1 workspace(s) named 'Hudson-Development-MASTER'. Creating workspace 'Hudson-Development-MASTER' owned by ''... Mapping '$//Development' to local folder 'c:\temp\workspace\x_Development' in workspace 'Hudson-Development-MASTER'... Created workspace 'Hudson-Development-MASTER'. Getting version 'C35974' to 'c:\temp\workspace\_Development'... Finished getting version 'C35974'. Retrieved 1627 resources.[Pipeline] }[Pipeline] // stage[Pipeline] withEnv[Pipeline] {[Pipeline] withEnv[Pipeline] {[Pipeline] stage[Pipeline] { (restore)[Pipeline] batc:\temp\workspace\_Development>nuget restore  ...

[JIRA] (JENKINS-58878) withCredentials hangs

2019-11-08 Thread jon.s...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jon Sten commented on  JENKINS-58878  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: withCredentials hangs   
 

  
 
 
 
 

 
 You're welcome, and thank you Devin Nusbaum for fixing the problem! I started to try to fix the bug, but became very fast confused and disoriented by all the different threads and objects involved, so I gave up . In other words, I appreciate experts like you that can fix these problems! I've given the linked experimental release a spin on our staging environment and I'm no longer able to reproduce the issue  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60101) can not change timezone when using Docker jenkinsci/blueocean

2019-11-08 Thread jenkins...@carlossanchez.eu (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Carlos Sanchez commented on  JENKINS-60101  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: can not change timezone when using Docker jenkinsci/blueocean   
 

  
 
 
 
 

 
 example?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60102) Getting "unexpected modal dialog" exception

2019-11-08 Thread ogon...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oliver Gondža edited a comment on  JENKINS-60102  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Getting "unexpected modal dialog" exception   
 

  
 
 
 
 

 
 OMFG, not again! Which test is failing for you this way? [1] [https://ci.jenkins.io/job/Core/job/acceptance-test-harness/job/master/197/testReport/junit/core/FormValidationTest/java_8_split3___validate/]  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60102) Getting "unexpected modal dialog" exception

2019-11-08 Thread ogon...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oliver Gondža commented on  JENKINS-60102  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Getting "unexpected modal dialog" exception   
 

  
 
 
 
 

 
 OMFG, not again! Which test is failing for you this way? [1] https://ci.jenkins.io/job/Core/job/acceptance-test-harness/job/master/197/testReport/junit/core/FormValidationTest/java_8_split3___validate/  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60101) can not change timezone when using Docker jenkinsci/blueocean

2019-11-08 Thread blankh...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 blank hang commented on  JENKINS-60101  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: can not change timezone when using Docker jenkinsci/blueocean   
 

  
 
 
 
 

 
 TZ not working   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60103) Cannot send junit results to Octane

2019-11-08 Thread vien...@poczta.fm (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 pretbc pretbc created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60103  
 
 
  Cannot send junit results to Octane   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Maria Narcisa Galan  
 
 
Components: 
 hp-application-automation-tools-plugin  
 
 
Created: 
 2019-11-08 09:47  
 
 
Environment: 
 Jenkins ver. 2.176.3  Micro Focus Application Automation Tools version 5.9  
 
 
Labels: 
 ALM Octane  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 pretbc pretbc  
 

  
 
 
 
 

 
 Cannot sent JUnits results to Octane while using  Micro Focus Application Automation Tools v5.9 When I do downgrade to v5.7 everything working fine Issue LOGS   08/11/2019 10:13:30,836 INFO [EventsServiceWorker-339 ] EventsServiceImpl : https://octane.orange-labs.fr?p=1001 sending [Run test:73:FINISHED, Declarative: Post Actions:73:STARTED] event/s ... 08/11/2019 10:13:32,922 INFO [EventsServiceWorker-339 ] EventsServiceImpl : https://octane.orange-labs.fr?p=1001 sending [Declarative: Post Actions:73:FINISHED] event/s ... 08/11/2019 10:13:34,009 INFO [Running CpsFlowExecutionOwner[functional/73:functional #73]] RunListenerForLogs : enqueued build 'functional #73' for log submission 08/11/2019 10:13:34,080 ERROR [Running CpsFlowExecutionOwner[functional/73:functional #73]] TestListener : failed to process test results java.io.IOException: Remote call on olsauto1 failed at hudson.remoting.Channel.call(Channel.java:963) ~[remoting-3.29.jar:?] at hudson.FilePath.act(FilePath.java:1070) ~[jenkins-core-2.176.3.jar:?] at hudson.FilePath.act(FilePath.java:1059) ~[jenkins-core-2.176.3.jar:?] at com.microfocus.application.automation.tools.octane.tests.junit.JUnitExtension.getTestResults(JUnitExtens

[JIRA] (JENKINS-60101) can not change timezone when using Docker jenkinsci/blueocean

2019-11-08 Thread jenkins...@carlossanchez.eu (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Carlos Sanchez commented on  JENKINS-60101  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: can not change timezone when using Docker jenkinsci/blueocean   
 

  
 
 
 
 

 
 as the stackoverflow post says, you can use the TZ env var  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-59998) After updating 2.190.1 jenkis builds are failing - Jenkins.instance is missing.

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Williams commented on  JENKINS-59998  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: After updating 2.190.1 jenkis builds are failing - Jenkins.instance is missing.   
 

  
 
 
 
 

 
 Is this related to: JENKINS-59992 ?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60102) Getting "unexpected modal dialog" exception

Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Latombe assigned an issue to Vincent Latombe  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60102  
 
 
  Getting "unexpected modal dialog" exception   
 

  
 
 
 
 

 
Change By: 
 Vincent Latombe  
 
 
Assignee: 
 Oliver Gondža Vincent Latombe  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60102) Getting "unexpected modal dialog" exception

Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Latombe started work on  JENKINS-60102  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
Change By: 
 Vincent Latombe  
 
 
Status: 
 Open In Progress  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60102) Getting "unexpected modal dialog" exception

Title: Message Title


 
 
 
 

 
 
 

 
   
 Vincent Latombe created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60102  
 
 
  Getting "unexpected modal dialog" exception   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Oliver Gondža  
 
 
Components: 
 acceptance-test-harness  
 
 
Created: 
 2019-11-08 09:38  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Vincent Latombe  
 

  
 
 
 
 

 
 When upgrading acceptance-test-harness I get the following exception. 

 

Caused by: org.openqa.selenium.UnhandledAlertException: Unexpected modal dialog (text: blabla): blabla
[redacted]
Session ID: bf00ad4e-12aa-4ee5-a6d7-a97ecdedb577
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
	at org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:214)
	at org.openqa.selenium.remote.ErrorHandler.createUnhandledAlertException(ErrorHandler.java:195)
	at org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:156)
	at org.openqa.selenium.remote.http.JsonHttpResponseCodec.reconstructValue(JsonHttpResponseCodec.java:40)
	at org.openqa.selenium.remote.http.AbstractHttpResponseCodec.decode(AbstractHttpResponseCodec.java:80)
	at org.openqa.selenium.remote.http.AbstractHttpResponseCodec.decode(AbstractHttpResponseCodec.java:44)
	at org.openqa.selenium.remote.HttpCommandExecutor.execute(HttpCommandExecutor.java:158)
	at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:548)
	at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:605)
	at org.openqa.selenium.remote.RemoteWebDriver.getWindowHandle(RemoteWebDriver.java:468)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ

[JIRA] (JENKINS-59998) After updating 2.190.1 jenkis builds are failing - Jenkins.instance is missing.

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Williams updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-59998  
 
 
  After updating 2.190.1 jenkis builds are failing - Jenkins.instance is missing.   
 

  
 
 
 
 

 
Change By: 
 Ian Williams  
 

  
 
 
 
 

 
 {code:java}19:49:00* Started by timer*19:49:00* Running as SYSTEM*19:49:00* [EnvInject] - Loading node environment variables.*19:49:00* Building remotely on [bgl-pc-build2|https://blr-bld28-lnx:9081/computer/bgl-pc-build2] in workspace /scratch/jenkins_slave_blr-bld18-lnx/workspace/pc_12.1_SP4*19:49:00* *19:49:00* Deleting project workspace... done*19:49:00* *19:49:03* FATAL: Jenkins.instance is missing. Read the documentation of Jenkins.getInstanceOrNull to see what you are doing wrong.*19:49:03* Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to bgl-pc-build2*19:49:03*   at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)*19:49:03*   at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)*19:49:03*   at hudson.remoting.Channel.call(Channel.java:957)*19:49:03*   at hudson.FilePath.act(FilePath.java:1072)*19:49:03*   at hudson.FilePath.act(FilePath.java:1061)*19:49:03*   at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:848)*19:49:03*   at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:786)*19:49:03*   at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)*19:49:03*   at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)*19:49:03*   at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)*19:49:03*   at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)*19:49:03*   at hudson.model.Run.execute(Run.java:1815)*19:49:03*   at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)*19:49:03*   at hudson.model.ResourceController.execute(ResourceController.java:97)*19:49:03*   at hudson.model.Executor.run(Executor.java:429)*19:49:03* java.lang.IllegalStateException: Jenkins.instance is missing. Read the documentation of Jenkins.getInstanceOrNull to see what you are doing wrong.*19:49:03*  at jenkins.model.Jenkins.get(Jenkins.java:772)*19:49:03*  at hudson.model.Hudson.getInstance(Hudson.java:77)*19:49:03*  at hudson.scm.SubversionSCM.createDefaultSVNOptions(SubversionSCM.java:963)*19:49:03*  at hudson.scm.SubversionSCM.createClientManager(SubversionSCM.java:953)*19:49:03*  at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:885)*19:49:03*  at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:872)*19:49:03*  at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3052)*19:49:03*  at hudson.remoting.UserRequest.perform(UserRequest.java:212)*19:49:03*  at hudson.remoting.UserRequest.perform(UserRequest.java:54)*19:49:03*  at hudson.remoting.Request$2.run(Request.java:369)*19:49:03*  at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)*19:49:03*  at java.util.concurrent.FutureTask.run(FutureTask.java:266)*19:49:03*  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor

[JIRA] (JENKINS-59998) After updating 2.190.1 jenkis builds are failing - Jenkins.instance is missing.

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Williams updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-59998  
 
 
  After updating 2.190.1 jenkis builds are failing - Jenkins.instance is missing.   
 

  
 
 
 
 

 
Change By: 
 Ian Williams  
 

  
 
 
 
 

 
 {code:java} 19:49:00 *  Started by timer* 19:49:00*  Running as SYSTEM*19:49:00* [EnvInject] - Loading node environment variables.*19:49:00* Building remotely on [bgl-pc-build2|https://blr-bld28-lnx:9081/computer/bgl-pc-build2] in workspace /scratch/jenkins_slave_blr-bld18-lnx/workspace/pc_12.1_SP4*19:49:00* *19:49:00* Deleting project workspace... done*19:49:00* *19:49:03* FATAL: Jenkins.instance is missing. Read the documentation of Jenkins.getInstanceOrNull to see what you are doing wrong.*19:49:03* Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to bgl-pc-build2*19:49:03*   at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)*19:49:03*   at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)*19:49:03*   at hudson.remoting.Channel.call(Channel.java:957)*19:49:03*   at hudson.FilePath.act(FilePath.java:1072)*19:49:03*   at hudson.FilePath.act(FilePath.java:1061)*19:49:03*   at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:848)*19:49:03*   at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:786)*19:49:03*   at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)*19:49:03*   at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)*19:49:03*   at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)*19:49:03*   at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)*19:49:03*   at hudson.model.Run.execute(Run.java:1815)*19:49:03*   at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)*19:49:03*   at hudson.model.ResourceController.execute(ResourceController.java:97)*19:49:03*   at hudson.model.Executor.run(Executor.java:429)*19:49:03* java.lang.IllegalStateException: Jenkins.instance is missing. Read the documentation of Jenkins.getInstanceOrNull to see what you are doing wrong.*19:49:03*  at jenkins.model.Jenkins.get(Jenkins.java:772)*19:49:03*  at hudson.model.Hudson.getInstance(Hudson.java:77)*19:49:03*  at hudson.scm.SubversionSCM.createDefaultSVNOptions(SubversionSCM.java:963)*19:49:03*  at hudson.scm.SubversionSCM.createClientManager(SubversionSCM.java:953)*19:49:03*  at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:885)*19:49:03*  at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:872)*19:49:03*  at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3052)*19:49:03*  at hudson.remoting.UserRequest.perform(UserRequest.java:212)*19:49:03*  at hudson.remoting.UserRequest.perform(UserRequest.java:54)*19:49:03*  at hudson.remoting.Request$2.run(Request.java:369)*19:49:03*  at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)*19:49:03*  at java.util.concurrent.FutureTask.run(FutureTask.java:266)*19:49:03*  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExe

[JIRA] (JENKINS-59998) After updating 2.190.1 jenkis builds are failing - Jenkins.instance is missing.

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Williams updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-59998  
 
 
  After updating 2.190.1 jenkis builds are failing - Jenkins.instance is missing.   
 

  
 
 
 
 

 
Change By: 
 Ian Williams  
 

  
 
 
 
 

 
 {code:java} *19:49:00* Started by timer*19:49:00* Running as SYSTEM*19:49:00* [EnvInject] - Loading node environment variables.*19:49:00* Building remotely on [bgl-pc-build2|https://blr-bld28-lnx:9081/computer/bgl-pc-build2] in workspace /scratch/jenkins_slave_blr-bld18-lnx/workspace/pc_12.1_SP4*19:49:00* *19:49:00* Deleting project workspace... done*19:49:00* *19:49:03* FATAL: Jenkins.instance is missing. Read the documentation of Jenkins.getInstanceOrNull to see what you are doing wrong.*19:49:03* Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to bgl-pc-build2*19:49:03*   at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)*19:49:03*   at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)*19:49:03*   at hudson.remoting.Channel.call(Channel.java:957)*19:49:03*   at hudson.FilePath.act(FilePath.java:1072)*19:49:03*   at hudson.FilePath.act(FilePath.java:1061)*19:49:03*   at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:848)*19:49:03*   at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:786)*19:49:03*   at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)*19:49:03*   at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)*19:49:03*   at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)*19:49:03*   at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)*19:49:03*   at hudson.model.Run.execute(Run.java:1815)*19:49:03*   at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)*19:49:03*   at hudson.model.ResourceController.execute(ResourceController.java:97)*19:49:03*   at hudson.model.Executor.run(Executor.java:429)*19:49:03* java.lang.IllegalStateException: Jenkins.instance is missing. Read the documentation of Jenkins.getInstanceOrNull to see what you are doing wrong.*19:49:03*  at jenkins.model.Jenkins.get(Jenkins.java:772)*19:49:03*  at hudson.model.Hudson.getInstance(Hudson.java:77)*19:49:03*  at hudson.scm.SubversionSCM.createDefaultSVNOptions(SubversionSCM.java:963)*19:49:03*  at hudson.scm.SubversionSCM.createClientManager(SubversionSCM.java:953)*19:49:03*  at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:885)*19:49:03*  at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:872)*19:49:03*  at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3052)*19:49:03*  at hudson.remoting.UserRequest.perform(UserRequest.java:212)*19:49:03*  at hudson.remoting.UserRequest.perform(UserRequest.java:54)*19:49:03*  at hudson.remoting.Request$2.run(Request.java:369)*19:49:03*  at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)*19:49:03*  at java.util.concurrent.FutureTask.run(FutureTask.java:266)*19:49:03*  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecut

[JIRA] (JENKINS-59656) executors widget makes it easy to interrupt the wrong build