date:20170203

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rick Liu edited a comment on  JENKINS-41722  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Job folder loading performance is worse when folder contains fewer items   
 

  
 
 
 
 

 
 Does  the Jenkins core somehow process more items than needed for Multibranch jobs? eg.{{*Projects*}} folder contains *34* cloudbees folder and processed only this 34 items.{{*Project-A*}} folder contains *6* items,but somehow Jenkins core processed more to include Multibranch branch jobs (those hundred of matrix jobs).  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41722) Job folder loading performance is worse when folder contains fewer items

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rick Liu commented on  JENKINS-41722  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Job folder loading performance is worse when folder contains fewer items   
 

  
 
 
 
 

 
 this issue is somewhat similar to JENKINS-18377 but not identical because the phenomenon I see apply to not only Role-base strategy but also to other different authorization.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41722) Job folder loading performance is worse when folder contains fewer items

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rick Liu commented on  JENKINS-41722  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Job folder loading performance is worse when folder contains fewer items   
 

  
 
 
 
 

 
 Does the Jenkins core somehow process more items than needed for Multibranch jobs?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41722) Job folder loading performance is worse when folder contains fewer items

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rick Liu updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41722  
 
 
  Job folder loading performance is worse when folder contains fewer items   
 

  
 
 
 
 

 
Change By: 
 Rick Liu  
 

  
 
 
 
 

 
 I have a tree-like structure job layout as below:|| "Projects" Cloudbees folder  | contains *34* subproject folder ||| || subproject: "Project-A" Cloudbees folder | contains *6* branch folders ( *5* multibranch job folder and *1* cloudbees folder ) ||| || || multibranch-job1 | contains 295 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job2 | contains 317 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job3 | contains 189 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job4 | contains 15 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job5 | contains 5 matrix jobs (75 x 2 matrix combination) ||| || || Cloudbees folder | contains 4 matrix jobs (75 x 2 matrix combination) ||| || subproject: Project-B Cloudbees folder |  ||| || || multibranch-job1 | ... ||| || || ... | ... ||| || ... || ... | ... |I found somehow no matter what kind of authorization strategy I choose,it's always taking longer time to open "{{*Project-A*}}" cloudbees folder (contains *6* items) than "{{*Projects*}}" folder (contains *34* items).Below is my benchmark:|| || Chrome || Chrome || Firefox || Firefox  Authorization Method || Open Projects Folder || Open Project-A Folder || Open Projects Folder || Open Project-A Folder  Anyone can do anything | 2.10 sec | 8.43 sec | 5.99 sec | 17.05 sec ||| Logged-in users can do anything | 3.97 sec | 9.94 sec | 7.97 sec | 20.06 sec ||| Initial default Role-based configuration - admin role | 8.22 sec | 14.54 sec | 16.47 sec | 28.55 sec ||| Role-based configuration - admin role with 119 Project roles | 18.81 sec | 31.95 sec | 37.7 sec | 65 |  I'm expecting it should be faster to open "{{*Project-A*}}" folder because it needs to process permission and load only *6* items,and slower to open "{{*Projects*}}" folder because it needs to process permissions and load for *34* items.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-41722) Job folder loading performance is worse when folder contains fewer items

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rick Liu updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41722  
 
 
  Job folder loading performance is worse when folder contains fewer items   
 

  
 
 
 
 

 
Change By: 
 Rick Liu  
 

  
 
 
 
 

 
 I have a tree-like structure job layout as below:|| "Projects" Cloudbees folder  | contains *34* subproject folder ||| || subproject: "Project-A" Cloudbees folder | contains *6* branch folders ( *5* multibranch job folder and *1* cloudbees folder ) ||| || || multibranch-job1 | contains 295 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job2 | contains 317 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job3 | contains 189 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job4 | contains 15 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job5 | contains 5 matrix jobs (75 x 2 matrix combination) ||| || || Cloudbees folder | contains 4 matrix jobs (75 x 2 matrix combination) ||| || subproject: Project-B Cloudbees folder |  ||| || || multibranch-job1 | ... ||| || || ... | ... ||| || ... || ... | ... |I found somehow no matter what kind of authorization strategy I choose,it's always taking longer time to open "{{*Project-A*}}" cloudbees folder (contains *6* items) than "{{*Projects*}}" folder (contains *34* items). I'm expecting it should be faster to open "{{*Project-A*}}" folder because it needs to process permission and load only *6* items,and slower to open "{{*Projects*}}" folder because it needs to process permissions and load for *34* items. Below is my benchmark:|| || Chrome || Chrome || Firefox || Firefox  Authorization Method || Open Projects Folder || Open Project-A Folder || Open Projects Folder || Open Project-A Folder  Anyone can do anything | 2.10 sec | 8.43 sec | 5.99 sec | 17.05 sec ||| Logged-in users can do anything | 3.97 sec | 9.94 sec | 7.97 sec | 20.06 sec ||| Initial default Role-based configuration - admin role | 8.22 sec | 14.54 sec | 16.47 sec | 28.55 sec ||| Role-based configuration - admin role with 119 Project roles | 18.81 sec | 31.95 sec | 37.7 sec | 65 |  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-41722) Job folder loading performance is worse when folder contains fewer items

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rick Liu updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41722  
 
 
  Job folder loading performance is worse when folder contains fewer items   
 

  
 
 
 
 

 
Change By: 
 Rick Liu  
 

  
 
 
 
 

 
 I have a tree-like structure job layout as below:|| "Projects" Cloudbees folder  | contains *34* subproject folder ||| || subproject: "Project-A" Cloudbees folder | contains *6* branch folders ( *5* multibranch job folder and *1* cloudbees folder ) ||| || || multibranch-job1 | contains 295 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job2 | contains 317 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job3 | contains 189 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job4 | contains 15 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job5 | contains 5 matrix jobs (75 x 2 matrix combination) ||| || || Cloudbees folder | contains 4 matrix jobs (75 x 2 matrix combination) ||| || subproject: Project-B Cloudbees folder |  ||| || || multibranch-job1 | ... ||| || || ... | ... ||| || ... || ... | ... |I found somehow no matter what kind of authorization strategy I choose,it's always taking longer time to open "{{*Project-A*}}" cloudbees folder (contains *6* items) than "{{*Projects*}}" folder (contains *34* items). I'm expecting it should be faster to open "{{*Project-A*}}" folder because it needs to process permission and load only *6* items,  and slower to open "{{*Projects*}}" folder because it needs to process permissions and load for *34* items.   Below is my benchmark:|| || Chrome || Chrome || Firefox || Firefox  Authorization Method || Open Projects Folder || Open Project-A Folder || Open Projects Folder || Open Project-A Folder  Anyone can do anything | 2.10 sec | 8.43 sec | 5.99 sec | 17.05 sec ||| Logged-in users can do anything | 3.97 sec | 9.94 sec | 7.97 sec | 20.06 sec ||| Initial default Role-based configuration - admin role | 8.22 sec | 14.54 sec | 16.47 sec | 28.55 sec ||| Role-based configuration - admin role with 119 Project roles | 18.81 sec | 31.95 sec | 37.7 sec | 65 | I'm expecting it should be faster to open "{{*Project-A*}}" folder because it needs to process permission and load only *6* items,and slower to open "{{*Projects*}}" folder because it needs to process permissions and load for *34* items.

[JIRA] (JENKINS-41722) Job folder loading performance is worse when folder contains fewer items

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rick Liu updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41722  
 
 
  Job folder loading performance is worse when folder contains fewer items   
 

  
 
 
 
 

 
Change By: 
 Rick Liu  
 
 
Summary: 
 Job folder loading performance  difference in tree-like job structure  is worse when folder contains fewer items  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41722) Job folder loading performance difference in tree-like job structure

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rick Liu updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41722  
 
 
  Job folder loading performance difference in tree-like job structure   
 

  
 
 
 
 

 
Change By: 
 Rick Liu  
 

  
 
 
 
 

 
 I have a tree-like structure job layout as below:|| "Projects" Cloudbees folder | contains *34* subproject folder ||| || subproject: "Project-A"  Cloudbees folder  | contains *6* branch folders ( *5* multibranch job folder and *1* cloudbees folder ) ||| || || multibranch-job1 | contains 295 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job2 | contains 317 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job3 | contains 189 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job4 | contains 15 matrix jobs (75 x 2 matrix combination) ||| || || multibranch-job5 | contains 5 matrix jobs (75 x 2 matrix combination) ||| || || Cloudbees folder | contains 4 matrix jobs (75 x 2 matrix combination) ||| || subproject: Project-B  Cloudbees folder  |  ||| || || multibranch-job1 | ... ||| || || ... | ... | || || ... || ... | ... |   I found somehow no matter what kind of authorization strategy I choose,it's always taking longer time to open "{{*Project-A*}}" cloudbees folder (contains *6* items) than "{{*Projects*}}" folder (contains *34* items).Below is my benchmark:|| || Chrome || Chrome || Firefox || Firefox  Authorization Method || Open Projects Folder || Open Project-A Folder || Open Projects Folder || Open Project-A Folder  Anyone can do anything | 2.10 sec | 8.43 sec | 5.99 sec | 17.05 sec ||| Logged-in users can do anything | 3.97 sec | 9.94 sec | 7.97 sec | 20.06 sec ||| Initial default Role-based configuration - admin role | 8.22 sec | 14.54 sec | 16.47 sec | 28.55 sec ||| Role-based configuration - admin role with 119 Project roles | 18.81 sec | 31.95 sec | 37.7 sec | 65 |  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-41722) Job folder loading performance difference in tree-like job structure

2017-02-03 Thread stephen.alan.conno...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rick Liu created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41722  
 
 
  Job folder loading performance difference in tree-like job structure   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Matthew DeTullio  
 
 
Components: 
 cloudbees-folder-plugin, core, multi-branch-project-plugin, role-strategy-plugin  
 
 
Created: 
 2017/Feb/04 2:55 AM  
 
 
Environment: 
 Ubuntu 14.04.5 LTS  OpenJDK 8u111  Jenkins v2.32.1  Folders Plugin v5.16  Multi-Branch Project Plugin v0.5.1  Role-based Authorization Strategy v2.3.2   Intel Xeon E5-2630  24 GB RAM  500 GB SSD x 5 (RAID-5)  1897 jobs in total on the server – (1799 Matrix jobs)  Role Strategy Project Role: 119  Total Users: 464 users   Client tested on Ubuntu 16.04 (64-bit)  Chromium-browser 55.0.2883.87  Firefox 50.1.0  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Rick Liu  
 

  
 
 
 
 

 
 I have a tree-like structure job layout as below: 
 

 
 
 "Projects" Cloudbees folder  
 contains 34 subproject folder  
 
 
  
 subproject: "Project-A"  
 contains 6 branch folders ( 5 multibranch job folder and 1 cloudbees folder )

[JIRA] (JENKINS-23607) BuildGraph page doesn't load if some builds are queued

2017-02-03 Thread eric_st...@discovery.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Eric Stein commented on  JENKINS-23607  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: BuildGraph page doesn't load if some builds are queued   
 

  
 
 
 
 

 
 Is there a reason that the buildgraph-view plugin now needs >=1.651.3 of jenkins? Did anything new that is needed get used? Our Jenkins is older than that  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41602) Global Shared Library git ref overrides the project repo git info

2017-02-03 Thread szanto...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Gabor Szanto commented on  JENKINS-41602  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Global Shared Library git ref overrides the project repo git info   
 

  
 
 
 
 

 
 In the meantime, any workaround for this?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41721) NodeJS Plugin fails when using the pipeline

2017-02-03 Thread saiim...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Simon GUEROUT updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41721  
 
 
  NodeJS Plugin fails when using the pipeline   
 

  
 
 
 
 

 
Change By: 
 Simon GUEROUT  
 
 
Summary: 
 NodeJS Plugin fails when using the pipeline  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41721) Plugin fails when using the pipeline

2017-02-03 Thread saiim...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Simon GUEROUT created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41721  
 
 
  Plugin fails when using the pipeline   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 nodejs-plugin  
 
 
Created: 
 2017/Feb/04 12:06 AM  
 
 
Environment: 
 Jenkins 2.44  
 
 
Priority: 
  Blocker  
 
 
Reporter: 
 Simon GUEROUT  
 

  
 
 
 
 

 
 When using a freestyle job, everything works fine. When setting up a pipeline, it fails : node { stage("Test") { wrap([$class: 'NodeJSBuildWrapper', nodeJSInstallationName:'5.12.0'])  { sh ''' node --version ''' }  } } java.lang.NullPointerException at jenkins.plugins.nodejs.tools.NodeJSInstallation.getBin(NodeJSInstallation.java:110) at jenkins.plugins.nodejs.tools.NodeJSInstallation.buildEnvVars(NodeJSInstallation.java:72) at jenkins.plugins.nodejs.NodeJSBuildWrapper.setUp(NodeJSBuildWrapper.java:112) at org.jenkinsci.plugins.workflow.steps.CoreWrapperStep$Execution.start(CoreWrapperStep.java:74) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:184) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:126) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108) at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:151) at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:21) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:115) at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149) at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146) at

[JIRA] (JENKINS-41121) GitHub Branch Source upgrade can cause a lot of rebuilds

Title: Message Title

Stephen Connolly commented on JENKINS-41121

Re: GitHub Branch Source upgrade can cause a lot of rebuilds

Morgan Goose Manually downloading plugins from https://repo.jenkins-ci.org/public/org/jenkins-ci/plugins/ is neither the normal way to install plugins nor the recommended way. When you manually download plugins you have to take responsibility to manually download the required dependencies. For the SCM API and Blue Ocean related updates that is potentially a list of updates that could grow to 72 plugins depending on what plugins and versions you have installed prior to upgrading... though an otherwise up to date system might only need 24 plugins... and if you do not have Blue Ocean installed that number could drop to somewhere between 7 and 9. Given that you have manually installed more than one of the plugins, my recommendation is that you download the ZIP file that I gave a link to in https://issues.jenkins-ci.org/browse/JENKINS-41661 and use the plugins in that ZIP file to update your instance. For future reference, the recommended path for installing plugins is via the update center. There are safety checks that the update center applies to help prevent issues. While we can agree that there are more additional safety checks needed, the limited checks it does have are better than no checks which is the net effect of manual downloading.

Add Comment

This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

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

[JIRA] (JENKINS-41720) I am trying to import jobs from my local Jenkins server. I am getting the below error. please can you find and let me know the issue is?

2017-02-03 Thread sivakumar.vun...@wdc.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 sivakumar vunnam created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41720  
 
 
  I am trying to import jobs from my local Jenkins server. I am getting the below error. please can you find and let me know the issue is?   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 image-2017-02-03-15-32-03-399.png  
 
 
Components: 
 job-import-plugin  
 
 
Created: 
 2017/Feb/03 11:35 PM  
 
 
Environment: 
 Installed Plugin  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 sivakumar vunnam  
 

  
 
 
 
 

 
 when I am trying to import jobs from my remote jenkins system. I am getting this kind of errors.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-41690) JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Steven Baker updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41690  
 
 
  JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)   
 

  
 
 
 
 

 
Change By: 
 Steven Baker  
 

  
 
 
 
 

 
 *Jenkins: v2.44**JIRA plugin: v2.3*In v2.3 (currently the latest) of the JIRA plugin, I believe there is a bug in JiraProjectProperty.The issue is in the setSites() method here:https://github.com/jenkinsci/jira-plugin/blob/7600eb9c12559119d9599cdeaa088862a5c6dfc3/src/main/java/hudson/plugins/jira/JiraProjectProperty.java#L94-L96It is currently written as follows:{noformat}public void setSites(JiraSite site) {sites.add(site);}{noformat}The issue specifically is that the setSites() is behaving more like an "add site" command.  This can result in duplicate JiraSite objects ending up in your config.*Steps to Reproduce:*I first noticed this tonight when attempting to configure the JIRA plugin with a Groovy script.  In the Groovy script (see below), I create a JiraSite object, then save it to the instance with "setSites()". Every time I run the Groovy script, however, an additional entry for my single JIRA site is added to my instance.{noformat}import hudson.plugins.jira.*import jenkins.model.*import java.net.URL ; // create JiraSite objectURL url = "" URL("http://foo.atlassian.net/")URL alternativeUrl = nullString userName = "he...@foo.com"String password = "my-password-here"boolean supportsWikiStyleComment = trueboolean recordScmChanges = trueString userIssuePattern = ""boolean updateJiraIssueForAllBuildStatus = trueString groupVisibility = ""String roleVisibility = ""boolean useHTTPAuth = falsedef site = new JiraSite(url, alternativeUrl, userName, password, supportsWikiStyleComment, recordScmChanges, userIssuePattern, updateJiraIssueForAllBuildStatus, groupVisibility, roleVisibility, useHTTPAuth)// call setSites() to save the JiraSitedef instance = Jenkins.getInstance()jiraPlugin = instance.getDescriptorByType(hudson.plugins.jira.JiraProjectProperty.DescriptorImpl)jiraPlugin.setSites(site)jiraPlugin.save(){noformat}*Expected Behavior:** Calling setSites() should behave like a true "set" operation.  * You should be able to call setSites() as many times as you want, but if you're only ever passing in one JiraSite, then you should end up with one JiraSite in your instance.*Actual Behavior:* * Calling setSites() is currently behaving like an "add" operation.  * If you run this script 10 times, but you're only ever passing in one JiraSite, you'll end up with 10 duplicate JIRA projects configured.

[JIRA] (JENKINS-41690) JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Steven Baker updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41690  
 
 
  JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)   
 

  
 
 
 
 

 
Change By: 
 Steven Baker  
 

  
 
 
 
 

 
 *Jenkins: v2.44**JIRA plugin: v2.3*In v2.3 (currently the latest) of the JIRA plugin, I believe there is a bug in JiraProjectProperty.The issue is in the setSites() method here:https://github.com/jenkinsci/jira-plugin/blob/7600eb9c12559119d9599cdeaa088862a5c6dfc3/src/main/java/hudson/plugins/jira/JiraProjectProperty.java#L94-L96It is currently written as follows:{noformat}public void setSites(JiraSite site) {sites.add(site);}{noformat}The issue specifically is that the setSites() is behaving more like an "add site" command.  This can result in duplicate JiraSite objects ending up in your config.*Steps to Reproduce:*I first noticed this tonight when attempting to configure the JIRA plugin with a Groovy script.  In the Groovy script (see below), I create a JiraSite object, then save it to the instance with "setSites()". Every time I run the Groovy script, however, an additional entry for my single JIRA site is added to my instance.{noformat}import hudson.plugins.jira.*import jenkins.model.*import java.net.URL; // create JiraSite object URL url = "" URL("http://foo.atlassian.net/")URL alternativeUrl = nullString userName = "he...@foo.com"String password = "my-password-here"boolean supportsWikiStyleComment = trueboolean recordScmChanges = trueString userIssuePattern = ""boolean updateJiraIssueForAllBuildStatus = trueString groupVisibility = ""String roleVisibility = ""boolean useHTTPAuth = false  def site = new JiraSite(url, alternativeUrl, userName, password, supportsWikiStyleComment, recordScmChanges, userIssuePattern, updateJiraIssueForAllBuildStatus, groupVisibility, roleVisibility, useHTTPAuth) // call setSites() to save the JiraSite def instance = Jenkins.getInstance()jiraPlugin = instance.getDescriptorByType(hudson.plugins.jira.JiraProjectProperty.DescriptorImpl)jiraPlugin.setSites(site)jiraPlugin.save(){noformat}*Expected Behavior:** Calling setSites() should behave like a true "set" operation.  * You should be able to call setSites() as many times as you want, but if you're only ever passing in one JiraSite, then you should end up with one JiraSite in your instance.*Actual Behavior:* * Calling setSites() is currently behaving like an "add" operation.  * If you run this script 10 times, but you're only ever passing in one JiraSite, you'll end up with 10 duplicate JIRA projects configured.

[JIRA] (JENKINS-41690) JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Steven Baker updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41690  
 
 
  JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)   
 

  
 
 
 
 

 
Change By: 
 Steven Baker  
 

  
 
 
 
 

 
 *Jenkins: v2.44**JIRA plugin: v2.3*In v2.3 (currently the latest) of the JIRA plugin, I believe there is a bug in JiraProjectProperty.The issue is in the setSites() method here:https://github.com/jenkinsci/jira-plugin/blob/7600eb9c12559119d9599cdeaa088862a5c6dfc3/src/main/java/hudson/plugins/jira/JiraProjectProperty.java#L94-L96It is currently written as follows:{noformat}public void setSites(JiraSite site) {sites.add(site);}{noformat}The issue specifically is that the setSites() is behaving more like an "add site" command.  This can result in duplicate JiraSite objects ending up in your config.*Steps to Reproduce:*I first noticed this tonight when attempting to configure the JIRA plugin with a Groovy script.  In the Groovy script (see below), I create a JiraSite object, then save it to the instance with "setSites()". Every time I run the Groovy script, however, an additional entry for my single JIRA site is added to my instance.{noformat}import hudson.plugins.jira.*import jenkins.model.*import java.net.URL;URL url = "" URL("http://foo.atlassian.net/")URL alternativeUrl = nullString userName = "he...@foo.com"String password = "my-password-here"boolean supportsWikiStyleComment = trueboolean recordScmChanges = trueString userIssuePattern = ""boolean updateJiraIssueForAllBuildStatus = trueString groupVisibility = ""String roleVisibility = ""boolean useHTTPAuth = falsedef site = new JiraSite(url, alternativeUrl, userName, password, supportsWikiStyleComment, recordScmChanges, userIssuePattern, updateJiraIssueForAllBuildStatus, groupVisibility, roleVisibility, useHTTPAuth)def instance = Jenkins.getInstance()jiraPlugin = instance.getDescriptorByType(hudson.plugins.jira.JiraProjectProperty.DescriptorImpl)jiraPlugin.setSites(site) instance jiraPlugin .save(){noformat}*Expected Behavior:** Calling setSites() should behave like a true "set" operation.  * You should be able to call setSites() as many times as you want, but if you're only ever passing in one JiraSite, then you should end up with one JiraSite in your instance.*Actual Behavior:* * Calling setSites() is currently behaving like an "add" operation.  * If you run this script 10 times, but you're only ever passing in one JiraSite, you'll end up with 10 duplicate JIRA projects configured.

[JIRA] (JENKINS-41719) Provided compatibility with the Job DSL plugin

2017-02-03 Thread petrikvanderve...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Petrik van der Velde created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41719  
 
 
  Provided compatibility with the Job DSL plugin   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Olivier Dagenais  
 
 
Components: 
 tfs-plugin  
 
 
Created: 
 2017/Feb/03 11:03 PM  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Petrik van der Velde  
 

  
 
 
 
 

 
 The Job DSL plugin allows generating jobs from a groovy script which makes it an ideal way to store job configurations in source control. We're moving from using TFS to jenkins and want to use the Job DSL plugin to generate the build configurations (we have about 4000 of them at the moment). Ideally the TFS plugin would have integration with the Job DSL plugin so that we would be able to easily generate job configurations for our TFS builds as well.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-41690) JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)

2017-02-03 Thread stephen.alan.conno...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Steven Baker updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41690  
 
 
  JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)   
 

  
 
 
 
 

 
Change By: 
 Steven Baker  
 

  
 
 
 
 

 
 *Jenkins: v2.44**JIRA plugin: v2.3*In v2.3 (currently the latest) of the JIRA plugin, I believe there is a bug in JiraProjectProperty.The issue is in the setSites() method here:https://github.com/jenkinsci/jira-plugin/blob/7600eb9c12559119d9599cdeaa088862a5c6dfc3/src/main/java/hudson/plugins/jira/JiraProjectProperty.java#L94-L96It is currently written as follows:{noformat}public void setSites(JiraSite site) {sites.add(site);}{noformat}The issue specifically is that the setSites() is behaving more like an "add site" command.  This can result in duplicate JiraSite objects ending up in your config.*Steps to Reproduce:*I first noticed this tonight when attempting to configure the JIRA plugin with a Groovy script.  In the Groovy script (see below), I create a JiraSite object, then save it to the instance with "setSites()". Every time I run the Groovy script, however, an additional entry for my single JIRA site is added to my instance.{noformat}import hudson.plugins.jira.*import jenkins.model.*import java.net.URL;URL url = "" URL("http://foo.atlassian.net/")URL alternativeUrl = nullString userName = "he...@foo.com"String password = "my-password-here"boolean supportsWikiStyleComment = trueboolean recordScmChanges = trueString userIssuePattern = ""boolean updateJiraIssueForAllBuildStatus = trueString groupVisibility = ""String roleVisibility = ""boolean useHTTPAuth = falsedef site = new JiraSite(url, alternativeUrl, userName, password, supportsWikiStyleComment, recordScmChanges, userIssuePattern, updateJiraIssueForAllBuildStatus, groupVisibility, roleVisibility, useHTTPAuth)def instance = Jenkins.getInstance()jiraPlugin = instance.getDescriptorByType(hudson.plugins.jira.JiraProjectProperty.DescriptorImpl)jiraPlugin.setSites(site) instance.save() {noformat}*Expected Behavior:** Calling setSites() should behave like a true "set" operation.  * You should be able to call setSites() as many times as you want, but if you're only ever passing in one JiraSite, then you should end up with one JiraSite in your instance.*Actual Behavior:* * Calling setSites() is currently behaving like an "add" operation.  * If you run this script 10 times, but you're only ever passing in one JiraSite, you'll end up with 10 duplicate JIRA projects configured.

[JIRA] (JENKINS-41164) Input in parallel does not show up on stage view

2017-02-03 Thread pluke...@articulate.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Luke van der Hoeven commented on  JENKINS-41164  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Input in parallel does not show up on stage view   
 

  
 
 
 
 

 
 I am seeing this as well. In the blue ocean views, both parallel paths waiting on input show up properly but you can only trigger/open the input acceptance dialog for the input that triggered first.  This video demonstrates what I see https://360.articulate.com/review/content/391d80b4-8c63-435b-8bf1-31440036c215/review. Let me know if I should file this separately for blue ocean.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41718) Support Build Failure Analyzer with Blue Ocean

2017-02-03 Thread shahmis...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 mishal shah created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41718  
 
 
  Support Build Failure Analyzer with Blue Ocean   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Tomas Westling  
 
 
Components: 
 blueocean-plugin, build-failure-analyzer-plugin  
 
 
Created: 
 2017/Feb/03 10:43 PM  
 
 
Environment: 
 Jenkins 2.32.2  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 mishal shah  
 

  
 
 
 
 

 
 Provide build failure information analyzed by the plugin in Blue Ocean UI.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-41717) Blue Ocean - Steps section should show full log for given step.

2017-02-03 Thread shahmis...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 mishal shah updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41717  
 
 
  Blue Ocean - Steps section should show full log for given step.
 

  
 
 
 
 

 
Change By: 
 mishal shah  
 
 
Summary: 
 Blue Ocean - Steps section should show full log for  the  given step.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-7139) HtmlPublisher should be able to handle wildcard paths to find multiple html files

2017-02-03 Thread most.wan...@gmx.at (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 most wanted commented on  JENKINS-7139  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: HtmlPublisher should be able to handle wildcard paths to find multiple html files
 

  
 
 
 
 

 
 Can i sponsor/support this feature?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-7139) HtmlPublisher should be able to handle wildcard paths to find multiple html files

2017-02-03 Thread most.wan...@gmx.at (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 most wanted edited a comment on  JENKINS-7139  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: HtmlPublisher should be able to handle wildcard paths to find multiple html files
 

  
 
 
 
 

 
 Can  i  I  sponsor/support this feature  to get it implemented again ?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41717) Blue Ocean - Steps section should show full log for the given step.

2017-02-03 Thread shahmis...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 mishal shah created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41717  
 
 
  Blue Ocean - Steps section should show full log for the given step.
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 blueocean-plugin  
 
 
Created: 
 2017/Feb/03 10:14 PM  
 
 
Environment: 
 Jenkins 2.32.2  BlueOcean 1.0.0-b21  
 
 
Priority: 
  Major  
 
 
Reporter: 
 mishal shah  
 

  
 
 
 
 

 
 "Show complete log" button will take me to plain text and it really hard to parse the information when pipeline steps are executed in parallel. Blue Ocean makes it easy to see steps with the UI diagram but truncating the log makes it impossible to find the error inside of blue ocean UI. Going into pain text requires downloading the logs and parsing the information by cat  | grep "[stage name]" this makes it really difficult to find issues.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-41121) GitHub Branch Source upgrade can cause a lot of rebuilds

2017-02-03 Thread morgan.go...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Morgan Goose commented on  JENKINS-41121  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: GitHub Branch Source upgrade can cause a lot of rebuilds   
 

  
 
 
 
 

 
 But there are already plugins available for update that explicitly require this version of the scm plugin. Withholding the release is breaking Jenkins stacks. Letting users only upgrade partially, causes Jenkins to suggests resolution of "old data" via Deleting said data. If a core plugin is the hub of any number of spoke plugins that require it's use, it's seem pretty disruptive to not release them all at the same time? I've already grabbed the two hpi files, and installed manually: 
 
github-organization-folder-1.6.hpi 
scm-api-2.0.2.hpi 
 from https://repo.jenkins-ci.org/public/org/jenkins-ci/plugins/ Was this release standard? Or did it follow a different track than usual?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41121) GitHub Branch Source upgrade can cause a lot of rebuilds

Title: Message Title


 
 
 
 

 
 
 

 
   
 Stephen Connolly commented on  JENKINS-41121  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: GitHub Branch Source upgrade can cause a lot of rebuilds   
 

  
 
 
 
 

 
 Here is the draft of the blog post to accompany Monday's release into the UC https://github.com/jenkins-infra/jenkins.io/pull/580  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41121) GitHub Branch Source upgrade can cause a lot of rebuilds

2017-02-03 Thread stephen.alan.conno...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Stephen Connolly edited a comment on  JENKINS-41121  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: GitHub Branch Source upgrade can cause a lot of rebuilds   
 

  
 
 
 
 

 
 [~morgan_goose] The issue was resolved with releases in the experimental update center. The plugin release has been completed and all tests are successful, but is currently being held back from the UCs by https://github.com/jenkinsci/backend-update-center2/pull/109 until Monday to allow for better responsiveness in the event of further issues.If you are eager to get the release, you can download this zip https://www.dropbox.com/s/5g4qm8gms53pxqc/scm-api.zip?dl=0 which has the latest versions of all the complete transitive dependency graph of Blue Ocean and SCM API (as Blue Ocean is required to be updated if you update SCM API) Otherwise, just wait until Monday  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41121) GitHub Branch Source upgrade can cause a lot of rebuilds

2017-02-03 Thread stephen.alan.conno...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Stephen Connolly commented on  JENKINS-41121  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: GitHub Branch Source upgrade can cause a lot of rebuilds   
 

  
 
 
 
 

 
 Morgan Goose The issue was resolved with releases in the experimental update center. The plugin release has been completed and all tests are successful, but is currently being held back from the UCs by https://github.com/jenkinsci/backend-update-center2/pull/109 until Monday to allow for better responsiveness in the event of further issues. If you are eager to get the release, you can download this zip https://www.dropbox.com/s/5g4qm8gms53pxqc/scm-api.zip?dl=0 which has the latest versions of all the complete transitive dependency graph of Blue Ocean and SCM API (as Blue Ocean is required to be updated if you update SCM API)  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-32402) Credentials binding fails to find creds when using a Parameterized Expression, but only for timed jobs

2017-02-03 Thread bpatto...@yahoo.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 bryan patton edited a comment on  JENKINS-32402  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Credentials binding fails to find creds when using a Parameterized _expression_, but only for timed jobs   
 

  
 
 
 
 

 
 I am having the same issue and to compound it when rebuilding the  project  task  it will work correctly.  It appears to be a difference between Jenkins identifying the credentials and binding them  and  or  not.    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-32402) Credentials binding fails to find creds when using a Parameterized Expression, but only for timed jobs

2017-02-03 Thread bpatto...@yahoo.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 bryan patton commented on  JENKINS-32402  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Credentials binding fails to find creds when using a Parameterized _expression_, but only for timed jobs   
 

  
 
 
 
 

 
 I am having the same issue and to compound it when rebuilding the project it will work correctly. It appears to be a difference between Jenkins identifying the credentials and binding them and not.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41716) Upgrade Breaks NodeJS Tool Installations

2017-02-03 Thread signu...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Matthew Sexton created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41716  
 
 
  Upgrade Breaks NodeJS Tool Installations   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 nodejs-plugin  
 
 
Created: 
 2017/Feb/03 9:33 PM  
 
 
Environment: 
 CentOS 7 x64  Jenkins 2.43 and 2.44  NodeJS Plugin 1.0  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Matthew Sexton  
 

  
 
 
 
 

 
 
 
All NodeJS Installations are completely removed from the Global Tool Configuration 
 
Upgrade from 2.42 to 2.43 wiped out all NodeJS versions 
Upgrade from 2.43 to 2.44 (after reinstalling tools) wiped out all NodeJS versions 
  
All jobs utilizing a NodeJS installation then break, even after the installations are re-added. 
 
To fix this you have to enter the job and simply hit 'Save' for the tool to update the configuration for the job to account for the newly installed version(s). 
  
 To my knowledge, this is not due to the upgrade to v1.0 of the NodeJS plugin (certainly before the 2.44 upgrade), but I would like to validate that.

[JIRA] (JENKINS-41339) Environment variables referencing other variables broken

2017-02-03 Thread nowayr...@icloud.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Will Normand commented on  JENKINS-41339  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Environment variables referencing other variables broken   
 

  
 
 
 
 

 
 Jesse Glick how would you set PATH to something like: $JAVA_HOME/bin:/opt/tools/bin:/opt/nodejs/bin:/opt/python/bin:/opt/composer/bin:/opt/go/$ {GOVERSION} /go/bin:$PATH This worked in 1.12 but I can't find the right combination of the plus sign syntax to get all of these variables to line up. The inline help isn't terribly clear. Even then, if I am reading this right I will have to create additional environment variables so I can use GOVERSION in the middle of the path?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-35096) Add support for Jenkins Pipeline to the cppcheck-plugin

2017-02-03 Thread marco.stef...@gmx.at (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Marco Steffan commented on  JENKINS-35096  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add support for Jenkins Pipeline to the cppcheck-plugin   
 

  
 
 
 
 

 
 A documentation on that will be provided (just don't know yet where to put it correctly...): Until that here is my test-command for the pipeline: stage "cppcheck" step([$class: 'CppcheckPublisher',  pattern: "testcppcheck*.xml", ignoreBlankFiles: false, threshold: "19",  allowNoReport: false, newThreshold: "", failureThreshold: "", newFailureThreshold: "", healthy: "", unHealthy: "", severityError: true, severityWarning: true, severityStyle: true, severityPerformance: true, severityInformation: true, severityNoCategory: true, severityPortability: true, xSize: 1000, ySize: 200, numBuildsInGraph: 0, displayAllErrors: true, displayErrorSeverity: true, displayWarningSeverity: true, displayStyleSeverity: true, displayPerformanceSeverity: true, displayInformationSeverity: true, displayNoCategorySeverity: true, displayPortabilitySeverity: true])  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41715) Git credentials selection + git ls-remote test of config is wonky

2017-02-03 Thread jbla...@kickflop.net (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jeff Blaine created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41715  
 
 
  Git credentials selection + git ls-remote test of config is wonky   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Mark Waite  
 
 
Components: 
 git-client-plugin  
 
 
Created: 
 2017/Feb/03 9:02 PM  
 
 
Environment: 
 Git-Client Plugin 2.2.0 AND 2.2.1  Git Plugin 3.0.1  Jenkins 2.15 and Jenkins 2.32.2 both testing  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Jeff Blaine  
 

  
 
 
 
 

 
 There's something goofy going on. When configuring a job to reference a Git repository, and choosing an associated SSH+Key credential for access, we're seeing the following after choosing the right credential. However, ignoring this red error in the UI, saving the job configuration, and using those configured credentials works fine. More strangeness described after the error below: Failed to connect to repository : Command "git ls-remote -h g...@gitlab.our.org:r701-cookbooks/r701-redhat-subs.git HEAD" returned status code 128: stdout: stderr: Permission denied, please try again. Permission denied, please try again. Received disconnect from xx.xx.10.102: 2: Too many authentication failures for git fatal: The remote end hung up unexpectedly This is of course gives users the idea that their credentials are wrong or broken, so they then go off wasting time on something that isn't a problem. The other strangeness, is that if we see this error (before saving), and try to "re-toggle" our right credentials by selecting "-- none --", the UI resets the selection to the credentials we'd previously set. That is: 
 
Brand new job 
Chose "Git" 
Type repo as

[JIRA] (JENKINS-41704) Clicking On `Cppcheck Results` From A Multi-Branch Pipeline Build Results In javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException

2017-02-03 Thread marco.stef...@gmx.at (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Marco Steffan commented on  JENKINS-41704  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Clicking On `Cppcheck Results` From A Multi-Branch Pipeline Build Results In javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException   
 

  
 
 
 
 

 
 The issue seems to be caused by the following line where it.owner returns null causing the exception: " page="sidepanel.jelly"/> CppcheckResult implements Serializable. One of its members is Run owner which is not serializable. Thus, owner remains null...  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41714) Docker Build and Publish Force Pull option needs to be changed

2017-02-03 Thread atay...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Alex Taylor created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41714  
 
 
  Docker Build and Publish Force Pull option needs to be changed   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Carlos Sanchez  
 
 
Components: 
 docker-build-publish-plugin  
 
 
Created: 
 2017/Feb/03 8:54 PM  
 
 
Environment: 
 Docker version 1.12.5  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Alex Taylor  
 

  
 
 
 
 

 
 For the Docker Build and Publish plugin, the `Force Pull` checkbox uses the --force option which has been deprecated in newer docker versions. Could we either remove that option or find a way around the --force no longer existing?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-38499) Not possible to trigger from jenkins pipeline

2017-02-03 Thread dant...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 dan tran commented on  JENKINS-38499  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Not possible to trigger from jenkins pipeline   
 

  
 
 
 
 

 
 plus 1. I have a pipeline jenkins file with a number of parameters such as vCenter info and other. I would like my user to customize the parameters via their own jekninsfile and then call this plugin passing thru all of its params to the main pipeline job. For now, I have user to manually create a freeslyle add all need params and trigger the pipeline.  Best if can use jenkinsfile to souce control the settings for each site  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-38998) Cannot trigger pipeline job

2017-02-03 Thread dant...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 dan tran commented on  JENKINS-38998  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cannot trigger pipeline job   
 

  
 
 
 
 

 
 I have no problem using freeslyle to trigger a pipeline (2.32.2)  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-34037) P4 polling always triggers if matrix axis is built on a different slave

2017-02-03 Thread timothy.fredrick...@seagate.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tim Fredrickson closed an issue as Fixed  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-34037  
 
 
  P4 polling always triggers if matrix axis is built on a different slave   
 

  
 
 
 
 

 
Change By: 
 Tim Fredrickson  
 
 
Status: 
 Resolved Closed  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-34037) P4 polling always triggers if matrix axis is built on a different slave

2017-02-03 Thread timothy.fredrick...@seagate.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tim Fredrickson resolved as Fixed  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-34037  
 
 
  P4 polling always triggers if matrix axis is built on a different slave   
 

  
 
 
 
 

 
Change By: 
 Tim Fredrickson  
 
 
Status: 
 Open Resolved  
 
 
Resolution: 
 Fixed  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41659) Stabilise ATH

2017-02-03 Thread tom.fenne...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tom FENNELLY edited a comment on  JENKINS-41659  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Stabilise ATH   
 

  
 
 
 
 

 
 Yeah  mye  maybe  Thor ... I just can't think why atm. Thanks.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41659) Stabilise ATH

2017-02-03 Thread tom.fenne...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tom FENNELLY commented on  JENKINS-41659  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Stabilise ATH   
 

  
 
 
 
 

 
 Yeah mye Thor ... I just can't think why atm. Thanks.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41535) NodeJS installation configuration is not persisted to file

Title: Message Title


 
 
 
 

 
 
 

 
   
 SCM/JIRA link daemon resolved as Fixed  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41535  
 
 
  NodeJS installation configuration is not persisted to file   
 

  
 
 
 
 

 
Change By: 
 SCM/JIRA link daemon  
 
 
Status: 
 Open Resolved  
 
 
Resolution: 
 Fixed  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41690) JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Steven Baker updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41690  
 
 
  JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)   
 

  
 
 
 
 

 
Change By: 
 Steven Baker  
 

  
 
 
 
 

 
 *Jenkins: v2.44**JIRA plugin: v2.3*In v2.3 (currently the latest) of the JIRA plugin, I believe there is a bug in JiraProjectProperty.The issue is in the setSites() method here:https://github.com/jenkinsci/jira-plugin/blob/7600eb9c12559119d9599cdeaa088862a5c6dfc3/src/main/java/hudson/plugins/jira/JiraProjectProperty.java#L94-L96It is currently written as follows:{noformat}public void setSites(JiraSite site) {sites.add(site);}{noformat}The issue specifically is that the setSites() is behaving more like an "add site" command.  This can result in duplicate JiraSite objects ending up in your config.*Steps to Reproduce:*I first noticed this tonight when attempting to configure the JIRA plugin with a Groovy script.  In the Groovy script (see below), I create a JiraSite object, then save it to the instance with "setSites()". Every time I run the Groovy script, however, an additional entry for my single JIRA site is added to my instance.{noformat}import hudson.plugins.jira.*import jenkins.model.*import java.net.URL;URL url = "" URL("http://foo.atlassian.net/")URL alternativeUrl = nullString userName = "he...@foo.com"String password = "my-password-here"boolean supportsWikiStyleComment = trueboolean recordScmChanges = trueString userIssuePattern = ""boolean updateJiraIssueForAllBuildStatus = trueString groupVisibility = ""String roleVisibility = ""boolean useHTTPAuth = falsedef site = new JiraSite(url, alternativeUrl, userName, password, supportsWikiStyleComment, recordScmChanges, userIssuePattern, updateJiraIssueForAllBuildStatus, groupVisibility, roleVisibility, useHTTPAuth)def instance = Jenkins.getInstance()jiraPlugin = instance.getDescriptorByType(hudson.plugins.jira.JiraProjectProperty.DescriptorImpl)jiraPlugin.setSites(site){noformat}*Expected Behavior:** Calling setSites() should behave like a true "set" operation.  * You should be able to  run this script 10  call setSites() as many  times  and  as you want, but  if you're only ever passing in one JiraSite, then you should end up with one JiraSite  object  in your  config  instance .*Actual Behavior:* * Calling setSites() is currently behaving like an "add" operation.  * If you run this script 10 times, but you're only ever passing in one JiraSite, you'll end up with 10 duplicate JIRA projects configured.

[JIRA] (JENKINS-41535) NodeJS installation configuration is not persisted to file

Title: Message Title


 
 
 
 

 
 
 

 
   
 SCM/JIRA link daemon commented on  JENKINS-41535  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: NodeJS installation configuration is not persisted to file   
 

  
 
 
 
 

 
 Code changed in jenkins User: Nikolas Falco Path: src/main/java/jenkins/plugins/nodejs/tools/NodeJSInstallation.java http://jenkins-ci.org/commit/nodejs-plugin/a15909ab05ac5a3267c92909c5a16bcaf9cc5482 Log: [FIX JENKINS-41535] Fix persistence of nodejs installation tool invoking load and save methods.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41690) JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Steven Baker updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41690  
 
 
  JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)   
 

  
 
 
 
 

 
Change By: 
 Steven Baker  
 

  
 
 
 
 

 
 *Jenkins: v2.44**JIRA plugin: v2.3*In v2.3 (currently the latest) of the JIRA plugin, I believe there is a bug in JiraProjectProperty.The issue is in the setSites() method here:https://github.com/jenkinsci/jira-plugin/blob/7600eb9c12559119d9599cdeaa088862a5c6dfc3/src/main/java/hudson/plugins/jira/JiraProjectProperty.java#L94-L96It is currently written as follows:{noformat}public void setSites(JiraSite site) {sites.add(site);}{noformat}The issue specifically is that the setSites() is behaving more like an "add site" command.  This can result in duplicate JiraSite objects ending up in your config. *Steps to Reproduce:* I first noticed this tonight when attempting to configure the JIRA plugin with a Groovy script.    In the Groovy script (see below), I create a JiraSite object, then save it to the instance with "setSites()". Every time I run the Groovy script, however, an additional entry for my single JIRA site is added to my instance. Here's the script I was running: {noformat}import hudson.plugins.jira.*import jenkins.model.*import java.net.URL;URL url = "" URL("http://foo.atlassian.net/")URL alternativeUrl = nullString userName = "he...@foo.com"String password = "my-password-here"boolean supportsWikiStyleComment = trueboolean recordScmChanges = trueString userIssuePattern = ""boolean updateJiraIssueForAllBuildStatus = trueString groupVisibility = ""String roleVisibility = ""boolean useHTTPAuth = falsedef site = new JiraSite(url, alternativeUrl, userName, password, supportsWikiStyleComment, recordScmChanges, userIssuePattern, updateJiraIssueForAllBuildStatus, groupVisibility, roleVisibility, useHTTPAuth)def instance = Jenkins.getInstance()jiraPlugin = instance.getDescriptorByType(hudson.plugins.jira.JiraProjectProperty.DescriptorImpl)jiraPlugin.setSites(site){noformat}*Expected Behavior:** Calling setSites() should behave like a true "set" operation.  * You should be able to run this script 10 times and if you're only ever passing in one JiraSite, then you should end up with one JiraSite object in your config.*Actual Behavior:* * Calling setSites() is currently behaving like an "add" operation.  * If you run this script 10 times, but you're only ever passing in one JiraSite, you'll end up with 10 duplicate JIRA projects configured.

[JIRA] (JENKINS-41690) JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Steven Baker updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41690  
 
 
  JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)   
 

  
 
 
 
 

 
Change By: 
 Steven Baker  
 

  
 
 
 
 

 
 *Jenkins: v2.44**JIRA plugin: v2.3*In v2.3 (currently the latest) of the JIRA plugin, I believe there is a bug in JiraProjectProperty.The issue is in the setSites() method here:https://github.com/jenkinsci/jira-plugin/blob/7600eb9c12559119d9599cdeaa088862a5c6dfc3/src/main/java/hudson/plugins/jira/JiraProjectProperty.java#L94-L96It is currently written as follows:{noformat}public void setSites(JiraSite site) {sites.add(site);}{noformat}The issue specifically is that the setSites() is behaving more like an "add site" command.  This can result in duplicate JiraSite objects ending up in your config.I first noticed this tonight when attempting to configure the JIRA plugin with a Groovy script.  In the Groovy script (see below), I  was configuring  create  a JiraSite object, then  saving  save  it to the instance with "setSites()". Every time I  ran  run  the Groovy script, however,  a duplicate  an additional  entry for my single JIRA site  would appear  is added to my instance .      Here's the script I was running:{noformat}import hudson.plugins.jira.*import jenkins.model.*import java.net.URL;URL url = "" URL("http://foo.atlassian.net/")URL alternativeUrl = nullString userName = "he...@foo.com"String password = "my-password-here"boolean supportsWikiStyleComment = trueboolean recordScmChanges = trueString userIssuePattern = ""boolean updateJiraIssueForAllBuildStatus = trueString groupVisibility = ""String roleVisibility = ""boolean useHTTPAuth = falsedef site = new JiraSite(url, alternativeUrl, userName, password, supportsWikiStyleComment, recordScmChanges, userIssuePattern, updateJiraIssueForAllBuildStatus, groupVisibility, roleVisibility, useHTTPAuth)def instance = Jenkins.getInstance()jiraPlugin = instance.getDescriptorByType(hudson.plugins.jira.JiraProjectProperty.DescriptorImpl)jiraPlugin.setSites(site){noformat}*Expected Behavior:** Calling setSites() should behave like a true "set" operation.  * You should be able to run this script 10 times and if you're only ever passing in one JiraSite, then you should end up with one JiraSite object in your config.*Actual Behavior:* * Calling setSites() is currently behaving like an "add" operation.  * If you run this script 10 times, but you're only ever passing in one JiraSite, you'll end up with 10 duplicate JIRA projects configured.

[JIRA] (JENKINS-41690) JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Steven Baker updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41690  
 
 
  JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)   
 

  
 
 
 
 

 
Change By: 
 Steven Baker  
 

  
 
 
 
 

 
 *Jenkins: v2.44**JIRA plugin: v2.3*In v2.3 (currently the latest) of the JIRA plugin, I believe there is a bug in JiraProjectProperty.The issue is in the setSites() method here:https://github.com/jenkinsci/jira-plugin/blob/7600eb9c12559119d9599cdeaa088862a5c6dfc3/src/main/java/hudson/plugins/jira/JiraProjectProperty.java#L94-L96 The "setSites" method It  is currently written as follows:{noformat}public void setSites(JiraSite site) {sites.add(site);}{noformat}The issue  specifically  is that the setSites() is behaving more like an "add site" command.  This can result in duplicate JiraSite objects ending up in your config.I first noticed this tonight when attempting to configure the JIRA plugin with a Groovy script.  In the Groovy script (see below), I was configuring a JiraSite object, then saving it to the instance with "setSites()". Every time I ran the Groovy script, however, a duplicate entry for my single JIRA site would appear.  Here's the script I was running:{noformat}import hudson.plugins.jira.*import jenkins.model.*import java.net.URL;URL url = "" URL("http://foo.atlassian.net/")URL alternativeUrl = nullString userName = "he...@foo.com"String password = "my-password-here"boolean supportsWikiStyleComment = trueboolean recordScmChanges = trueString userIssuePattern = ""boolean updateJiraIssueForAllBuildStatus = trueString groupVisibility = ""String roleVisibility = ""boolean useHTTPAuth = falsedef site = new JiraSite(url, alternativeUrl, userName, password, supportsWikiStyleComment, recordScmChanges, userIssuePattern, updateJiraIssueForAllBuildStatus, groupVisibility, roleVisibility, useHTTPAuth)def instance = Jenkins.getInstance()jiraPlugin = instance.getDescriptorByType(hudson.plugins.jira.JiraProjectProperty.DescriptorImpl)jiraPlugin.setSites(site){noformat}*Expected Behavior:** Calling setSites() should behave like a true "set" operation.  * You should be able to run this script 10 times and if you're only ever passing in one JiraSite, then you should end up with one JiraSite object in your config.*Actual Behavior:* * Calling setSites() is currently behaving like an "add" operation.  * If you run this script 10 times, but you're only ever passing in one JiraSite, you'll end up with 10 duplicate JIRA projects configured.

[JIRA] (JENKINS-41690) JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Steven Baker updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41690  
 
 
  JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)   
 

  
 
 
 
 

 
Change By: 
 Steven Baker  
 

  
 
 
 
 

 
 *Jenkins: v2.44**JIRA plugin: v2.3*In v2.3 (currently the latest) of the JIRA plugin, I believe there is a bug in JiraProjectProperty.The issue is in the setSites() method here:https://github.com/jenkinsci/jira-plugin/blob/7600eb9c12559119d9599cdeaa088862a5c6dfc3/src/main/java/hudson/plugins/jira/JiraProjectProperty.java#L94-L96The "setSites" method is currently written as follows:{noformat}public void setSites(JiraSite site) {sites.add(site);}{noformat}The issue is that the setSites() is behaving more like an "add site" command.  This can result in duplicate JiraSite objects ending up in your config.I first noticed this tonight when attempting to configure the JIRA plugin with a Groovy script.  In the Groovy script (see below), I was configuring a JiraSite object, then saving it to the instance with "setSites()". Every time I ran the Groovy script, however, a duplicate entry for my single JIRA site would appear.  Here's the script I was running:{noformat}import hudson.plugins.jira.*import jenkins.model.*import java.net.URL;URL url = "" URL("http://foo.atlassian.net/")URL alternativeUrl = nullString userName = "he...@foo.com"String password = "my-password-here"boolean supportsWikiStyleComment = trueboolean recordScmChanges = trueString userIssuePattern = ""boolean updateJiraIssueForAllBuildStatus = trueString groupVisibility = ""String roleVisibility = ""boolean useHTTPAuth = falsedef site = new JiraSite(url, alternativeUrl, userName, password, supportsWikiStyleComment, recordScmChanges, userIssuePattern, updateJiraIssueForAllBuildStatus, groupVisibility, roleVisibility, useHTTPAuth)def instance = Jenkins.getInstance()jiraPlugin = instance.getDescriptorByType(hudson.plugins.jira.JiraProjectProperty.DescriptorImpl)jiraPlugin.setSites(site){noformat}*Expected Behavior:** Calling setSites() should behave like a true "set" operation.   *   You should be able to run this script 10 times , but  and  if you're only ever passing in one JiraSite, then you should end up with one JiraSite object in your config.*Actual Behavior:* * Calling setSites() is currently behaving like an "add" operation.   *   If you run this script 10 times, but you're only ever passing in one JiraSite, you'll end up with 10 duplicate JIRA projects configured.

[JIRA] (JENKINS-41713) not able to see the jenkins feature

2017-02-03 Thread bala.devaraj...@xenatix.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Balan Devarajulu assigned an issue to Balan Devarajulu  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41713  
 
 
  not able to see the jenkins feature
 

  
 
 
 
 

 
Change By: 
 Balan Devarajulu  
 
 
Assignee: 
 Balan Devarajulu  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41713) not able to see the jenkins feature

2017-02-03 Thread bala.devaraj...@xenatix.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Balan Devarajulu created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41713  
 
 
  not able to see the jenkins feature
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 windows-azure-storage-plugin  
 
 
Created: 
 2017/Feb/03 7:49 PM  
 
 
Environment: 
 Jenkins running on Windows server 2012 and installed Jenkins version 2.32  I have installed windows Azure storage plugin but not able to see the features  
 
 
Labels: 
 plugin  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Balan Devarajulu  
 

  
 
 
 
 

 
 I have installed windows Azure storage plugin and not able to see the option in the Build section "Download from Microsoft Azure Blob Storage" but it is showing in the post build action to upload it to Azure. I'm missing the download option.  Can you please help me out  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-41659) Stabilise ATH

2017-02-03 Thread tscher...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Thorsten Scherler commented on  JENKINS-41659  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Stabilise ATH   
 

  
 
 
 
 

 
 When I first started to developed the ATH tests I ran into the problem that I was killing a run before it ended. That resulted that I had to restart ./run  As long I allowed jenkins to finish a run I did not had that problem.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41690) JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Steven Baker updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41690  
 
 
  JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)   
 

  
 
 
 
 

 
Change By: 
 Steven Baker  
 

  
 
 
 
 

 
 *Jenkins: v2.44**JIRA plugin: v2.3*In v2.3 (currently the latest) of the JIRA plugin, I believe there is a bug in JiraProjectProperty.The issue is in the setSites() method here:https://github.com/jenkinsci/jira-plugin/blob/7600eb9c12559119d9599cdeaa088862a5c6dfc3/src/main/java/hudson/plugins/jira/JiraProjectProperty.java#L94-L96The "setSites" method is currently written as follows:{noformat}public void setSites(JiraSite site) {sites.add(site);}{noformat} The issue is that the setSites() is behaving more like an "add site" command.  This can result in duplicate JiraSite objects ending up in your config. I first noticed this tonight when attempting to configure the JIRA plugin with a Groovy script.      In the Groovy script (see below), I was configuring a JiraSite object, then saving it to the instance with "setSites()". Every time I ran the Groovy script,  however,  a duplicate entry for my single JIRA site would appear.      Here's the script I was running:{noformat}import hudson.plugins.jira.*import jenkins.model.*import java.net.URL;URL url = "" URL("http://foo.atlassian.net/")URL alternativeUrl = nullString userName = "he...@foo.com"String password = "my-password-here"boolean supportsWikiStyleComment = trueboolean recordScmChanges = trueString userIssuePattern = ""boolean updateJiraIssueForAllBuildStatus = trueString groupVisibility = ""String roleVisibility = ""boolean useHTTPAuth = falsedef site = new JiraSite(url, alternativeUrl, userName, password, supportsWikiStyleComment, recordScmChanges, userIssuePattern, updateJiraIssueForAllBuildStatus, groupVisibility, roleVisibility, useHTTPAuth)def instance = Jenkins.getInstance()jiraPlugin = instance.getDescriptorByType(hudson.plugins.jira.JiraProjectProperty.DescriptorImpl)jiraPlugin.setSites(site){noformat}*Expected Behavior:** Calling setSites() should behave like a true "set" operation.  You should be able to run this script 10 times, but if you're only ever passing in one JiraSite, then  that's how many  you  should  be on the project  end up with one JiraSite object in your config .*Actual Behavior:* * Calling setSites() is currently behaving like an "add" operation.  If you run this script 10 times, but you're only ever passing in one JiraSite, you'll end up with 10 duplicate JIRA projects configured.

[JIRA] (JENKINS-41690) JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Steven Baker updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41690  
 
 
  JiraProjectProperty.setSites() doesn't set sites, it adds them (resulting in duplicate sites)   
 

  
 
 
 
 

 
Change By: 
 Steven Baker  
 

  
 
 
 
 

 
 *Jenkins: v2.44**JIRA plugin: v2.3*In v2.3 (currently the latest) of the JIRA plugin, I believe there is a bug in JiraProjectProperty.The issue is in the setSites() method here:https://github.com/jenkinsci/jira-plugin/blob/7600eb9c12559119d9599cdeaa088862a5c6dfc3/src/main/java/hudson/plugins/jira/JiraProjectProperty.java#L94-L96The "setSites" method is currently written as follows:{noformat}public void setSites(JiraSite site) {sites.add(site);}{noformat} Instead,  I  believe it should be:{noformat}public void setSites(JiraSite site) {sites.clear()sites.add(site);}{noformat}I  first noticed this tonight when attempting to configure the JIRA plugin with a Groovy script.  In the Groovy script (see below), I was configuring a JiraSite object, then saving it to the instance with "setSites()". Every time I ran the Groovy script, a  brand new  duplicate entry for my single  JIRA site would appear  in Jenkins -- one, then two, then three, then four, etc .  Here's the script , which will demonstrate the buggy behavior  I was running :{noformat}import hudson.plugins.jira.*import jenkins.model.*import java.net.URL;URL url = "" URL("http://foo.atlassian.net/")URL alternativeUrl = nullString userName = "he...@foo.com"String password = "my-password-here"boolean supportsWikiStyleComment = trueboolean recordScmChanges = trueString userIssuePattern = ""boolean updateJiraIssueForAllBuildStatus = trueString groupVisibility = ""String roleVisibility = ""boolean useHTTPAuth = falsedef site = new JiraSite(url, alternativeUrl, userName, password, supportsWikiStyleComment, recordScmChanges, userIssuePattern, updateJiraIssueForAllBuildStatus, groupVisibility, roleVisibility, useHTTPAuth)def instance = Jenkins.getInstance()jiraPlugin = instance.getDescriptorByType(hudson.plugins.jira.JiraProjectProperty.DescriptorImpl)jiraPlugin.setSites(site){noformat}* Actual Expected  Behavior:** Calling setSites()  should behave like a true  " n set "  operation.  You should be able to run this script 10  times  results , but if you're only ever passing  in  "n" copies of  one JiraSite, then that's how many should be on  the  JIRA site in the Jenkins instance  project .   :-( * Expected Actual  Behavior:** Calling setSites()  is currently behaving like an  " n add "  operation.  If you run this script 10  times  results , but you're only ever passing  in  ONE copy of your  one JiraSite, you'll end up with 10 duplicate  JIRA  site in your Jenkins instance  projects configured .

[JIRA] (JENKINS-32167) ISVNAuthentication provider did not provide credentials

2017-02-03 Thread stefan.wal...@lisec.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Walter edited a comment on  JENKINS-32167  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: ISVNAuthentication provider did not provide credentials   
 

  
 
 
 
 

 
 The issue still persists even with snapshot 2.7.2. {{ No changes for https://** since the previous buildUsing sole credentials  in realm ‘ Your AD Username/Password for SVN’hudson.util.IOException2: revision check failed on https://** at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:208) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:138) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860) at hudson.scm.SCM.checkout(SCM.java:495) at hudson.model.AbstractProject.checkout(AbstractProject.java:1278) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) at hudson.model.Run.execute(Run.java:1728) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:404)Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:798) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:391) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:862) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:698) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:189) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:195) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:46) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:194) ... 12 moreCaused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:728) ...

[JIRA] (JENKINS-32167) ISVNAuthentication provider did not provide credentials

2017-02-03 Thread stefan.wal...@lisec.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Walter edited a comment on  JENKINS-32167  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: ISVNAuthentication provider did not provide credentials   
 

  
 
 
 
 

 
 The issue still persists even with snapshot 2.7.2.{{No changes for https://** since the previous buildUsing sole credentials  in realm ‘ Your AD Username/Password for SVN’hudson.util.IOException2: revision check failed on https://** at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:208) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:138) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860) at hudson.scm.SCM.checkout(SCM.java:495) at hudson.model.AbstractProject.checkout(AbstractProject.java:1278) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) at hudson.model.Run.execute(Run.java:1728) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:404)Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:798) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:391) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:862) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:698) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:189) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:195) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:46) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:194) ... 12 moreCaused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:728) ... 30

[JIRA] (JENKINS-32167) ISVNAuthentication provider did not provide credentials

2017-02-03 Thread stefan.wal...@lisec.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Stefan Walter commented on  JENKINS-32167  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: ISVNAuthentication provider did not provide credentials   
 

  
 
 
 
 

 
 The issue still persists even with snapshot 2.7.2. {{No changes for https://** since the previous build Using sole credentials  in realm ‘ Your AD Username/Password for SVN’ hudson.util.IOException2: revision check failed on https://** at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:208) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:138) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860) at hudson.scm.SCM.checkout(SCM.java:495) at hudson.model.AbstractProject.checkout(AbstractProject.java:1278) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) at hudson.model.Run.execute(Run.java:1728) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:404) Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:798) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:391) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:862) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:698) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:189) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:195) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:46) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:194) ... 12 more Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at

[JIRA] (JENKINS-22591) Does not spawn build if a branch refers to the same SHA1 as another already built branch

2017-02-03 Thread gustavo.kamb...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Gustavo Kambara edited a comment on  JENKINS-22591  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Does not spawn build if a branch refers to the same SHA1 as another already built branch   
 

  
 
 
 
 

 
 Hello,While I was reading some JIRA ticket, I found the non-official Jenkins plugin [Git Chooser Build Branches|https://github.com/phemmer/jenkins-git-chooser-build-branches], which defines a build branch strategy that allows Jenkins to build the same commit that was built previously, considering a different branch.I am going to describe step-by-step how to configure, from webhook (Bitbucket) to the job configuration, in case someone else is trying to achieve the same goals.*1. Install the following Jenkins plugins:*- [Git|https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin]- [Git Chooser Build Branches|https://github.com/phemmer/jenkins-git-chooser-build-branches] - you'll have to clone the repository, compile (maven) and install manually.- [Bitbucket|https://wiki.jenkins-ci.org/display/JENKINS/BitBucket+Plugin]*2. On Bitbucket:*- Access your repository settings- Access Webhooks -> Add Webhook- In URL, you should inform: YOUR_JENKINS_URL/bitbucket-hook/. Note that the trailing slash is required.- Configure the remaining fields as you wish*3. On Jenkins:*- In your job, mark "This build is parameterized"- Add a string parameter BRANCH with the wildcard that you want, say origin/*.- Configure your SCM and in "Branches to build", inform the same parameter specified before. In our case, $BRANCH.- In Git "Additional Behaviours", add "Strategy for choosing what to build", selecting "Build branches". Also, add "Force polling using workspace".- In "Build Triggers", check "Build when a change is pushed to BitBucket".That's it. When you push something in your repository (branch creation or push in existing branches), the job will be triggered. This build strategy could be included in Git plugin, so we have centralized configuration.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

[JIRA] (JENKINS-41535) NodeJS installation configuration is not persisted to file

2017-02-03 Thread tomislav.pasa...@javelingroup.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Nikolas Falco commented on  JENKINS-41535  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: NodeJS installation configuration is not persisted to file   
 

  
 
 
 
 

 
 I found the issue, my mistake on persistence. As workaround you could do "reload configuration from disk" from "manage jenkins" menu to load previous. Anyway any changes will not be persisted, I'm working on it to release 1.0.1 ASAP  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41535) NodeJS installation configuration is not persisted to file

2017-02-03 Thread mat...@mathin.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Dan Ebert commented on  JENKINS-41535  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: NodeJS installation configuration is not persisted to file   
 

  
 
 
 
 

 
 I wonder if the root cause of this is similar to JENKINS-38809  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41711) Prevent installation of plugins with unresolvable dependencies

2017-02-03 Thread ryan.campb...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 recampbell updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41711  
 
 
  Prevent installation of plugins with unresolvable dependencies   
 

  
 
 
 
 

 
Change By: 
 recampbell  
 

  
 
 
 
 

 
 The update center and setup wizard allows users to install plugins with unresolved dependencies. In this case, the update center meta-data presents a plugin having a dependency which cannot be resolved from any available update center. The user is presently able to install the plugin, but when Jenkins starts up, it will fail to initialize due to the unresolved dependencies.The setupwizard and update center should not allow the user to screw up their installation and thereby protect the user from mistakes or time-delays in publishing dependencies. Instead, the setupwizard and the update center should display warnings that the plugin dependencies cannot be satisified and which dependencies are missing.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups

[JIRA] (JENKINS-22591) Does not spawn build if a branch refers to the same SHA1 as another already built branch

2017-02-03 Thread gustavo.kamb...@gmail.com (JIRA)

Title: Message Title

Gustavo Kambara commented on JENKINS-22591

Re: Does not spawn build if a branch refers to the same SHA1 as another already built branch

Hello, While I was reading some JIRA ticket, I found the non-official Jenkins plugin Git Chooser Build Branches, which defines a build branch strategy that allows Jenkins to build the same commit that was built previously, considering a different branch. I am going to describe step-by-step how to configure, from webhook (Bitbucket) to the job configuration, in case someone else is trying to achieve the same goals. 1. Install the following Jenkins plugins:

Git
Git Chooser Build Branches - you'll have to clone the repository, compile (maven) and install manually.
Bitbucket
2. On Bitbucket:

Access your repository settings
Access Webhooks -> Add Webhook
In URL, you should inform: YOUR_JENKINS_URL/bitbucket-hook/. Note that the trailing slash is required.
Configure the remaining fields as you wish
3. On Jenkins:

In your job, mark "This build is parameterized"
Add a string parameter BRANCH with the wildcard that you want, say origin/*.
Configure your SCM and in "Branches to build", inform the same parameter specified before. In our case, $BRANCH.
In Git "Additional Behaviours", add "Strategy for choosing what to build", selecting "Build branches". Also, add "Force polling using workspace".
In "Build Triggers", check "Build when a change is pushed to BitBucket".
That's it. When you push something in your repository (branch creation or push in existing branches), the job will be triggered.

Add Comment

[JIRA] (JENKINS-41121) GitHub Branch Source upgrade can cause a lot of rebuilds

2017-02-03 Thread morgan.go...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Morgan Goose commented on  JENKINS-41121  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: GitHub Branch Source upgrade can cause a lot of rebuilds   
 

  
 
 
 
 

 
 Stephen Connolly It doesn't look like the scm-api >= 2.0 has actually been released: http://updates.jenkins-ci.org/download/plugins/scm-api/  Are you sure that this can be closed?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41705) Unable to install bitbucket-branch-source 2.0.2 due to broken dependency

2017-02-03 Thread pay...@oclc.org (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tim Payne commented on  JENKINS-41705  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Unable to install bitbucket-branch-source 2.0.2 due to broken dependency   
 

  
 
 
 
 

 
 https://updates.jenkins-ci.org/download/plugins/scm-api/ does not currently contain anything above v1.3. This is causing lots of plugin dependency errors!  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-40862) Upstream project trigger tip revision error

2017-02-03 Thread r...@currah.ca (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ryan Currah commented on  JENKINS-40862  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Upstream project trigger tip revision error   
 

  
 
 
 
 

 
 We are getting the same issue on Jenkins 2.40 and it seems to be related to upgrading to scm 2.0. We have tried using "build job" and "triggerRemoteJob" functions and both result in the same error. build job: 

 

build job: 'eis-factory-images/efr/helloworld/master', parameters: [string(name: 'GIT_BRANCH', value: 'master')]
 

 triggerRemoteJob: 

 

triggerRemoteJob mode: [$class: 'TrackProgressAwaitResult', scheduledTimeout: [timeoutStr: ''], startedTimeout: [timeoutStr: ''], timeout: [timeoutStr: '1d'], whenFailure: [$class: 'StopAsFailure'], whenScheduledTimeout: [$class: 'ContinueAsIs'], whenStartedTimeout: [$class: 'ContinueAsIs'], whenTimeout: [$class: 'ContinueAsFailure'], whenUnstable: [$class: 'ContinueAsUnstable']], remotePathMissing: [$class: 'ContinueAsIs'], remotePathUrl: "jenkins://323n1233j123123123/eis-factory-images/efr/helloworld/master
 

 Results in 

 

Started by upstream project "eis-factory-images/pipeline_test" build number 4
originally caused by:
 Started by user Ryan Currah (Ryan.Currah)
ERROR: Could not determine exact tip revision of master; falling back to nondeterministic checkout


Caught: hudson.AbortException: Could not determine exact tip revision of master
[Pipeline] error
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // load
[Pipeline] }
[Pipeline] // dir
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
[Bitbucket] Notifying commit build result
[Bitbucket] Build result notified
ERROR: Could not determine exact tip revision of master
Finished: FAILURE
 

  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-28877) Bitbucket Plugin unable to parse Bitbucket webhook response json

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tomislav Pasalic edited a comment on  JENKINS-28877  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Bitbucket Plugin unable to parse Bitbucket webhook response json   
 

  
 
 
 
 

 
 I have this issue as well. Using Jenkins 2.44 and bitbucket plugin 1.1.5.Using on = - premise Bitbucket server 4.11.1Jenkins receives the payload:{code}{ "slug":"XXX", "id":94, "name":"XXX", "scmId":"git", "state":"AVAILABLE", "statusMessage":"Available", "forkable":true, "project":{  "key":"XXX",  "id":XX,  "name":"XXX XXX",  "public":false,  "type":"NORMAL" }, "public":false}{code}And throws the same exception as in description of this ticket with important part being:{code}Caused by: net.sf.json.JSONException: JSONObject["user"] not found.{code}Any idea about when this will be fixed or a suggestion of what I may have misconfigured?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-28877) Bitbucket Plugin unable to parse Bitbucket webhook response json

2017-02-03 Thread tomislav.pasa...@javelingroup.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tomislav Pasalic edited a comment on  JENKINS-28877  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Bitbucket Plugin unable to parse Bitbucket webhook response json   
 

  
 
 
 
 

 
 I have this issue as well. Using Jenkins 2.44 and bitbucket plugin 1.1.5. Using on=premise Bitbucket server 4.11.1 Jenkins receives the payload:{code}{ "slug":"XXX", "id":94, "name":"XXX", "scmId":"git", "state":"AVAILABLE", "statusMessage":"Available", "forkable":true, "project":{  "key":"XXX",  "id":XX,  "name":"XXX XXX",  "public":false,  "type":"NORMAL" }, "public":false}{code}And throws the same exception as in description of this ticket with important part being:{code}Caused by: net.sf.json.JSONException: JSONObject["user"] not found.{code}Any idea about when this will be fixed or a suggestion of what I may have misconfigured?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41535) NodeJS installation configuration is not persisted to file

Title: Message Title


 
 
 
 

 
 
 

 
   
 Nikolas Falco commented on  JENKINS-41535  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: NodeJS installation configuration is not persisted to file   
 

  
 
 
 
 

 
 ok let me try  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41535) NodeJS installation configuration is not persisted to file

Title: Message Title


 
 
 
 

 
 
 

 
   
 Nikolas Falco commented on  JENKINS-41535  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: NodeJS installation configuration is not persisted to file   
 

  
 
 
 
 

 
 Ok I've try with latest Jenkins LTS (2.32.2) Steps on ubuntu server 
 
following the guide on jenkins site to install on Ubuntu server (new created virtual machine) 
access to http://localhost:8080 
put the secure token to proceed configure 
unselect all plugins (no plugin installed) 
proceed as admin 
disable security (so I can skip steps to setup users) 
install nodejs 0.2.2 from HERE 
add two Nodejs installation Node 6.x and Node 5.x. It create the old file nodejs.xml 
create a job the use one of configured tool 
restart server 
update nodejs plugin to 1.0 
restart server 
goto manage jenkins and check for installation tools 
tools are there, nodejs.xml not exist anymore and jenkins.plugins.nodejs.tools.NodeJSInstallation.xml appears  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

[JIRA] (JENKINS-41535) NodeJS installation configuration is not persisted to file

2017-02-03 Thread ro...@khobbits.co.uk (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Robert Gornall commented on  JENKINS-41535  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: NodeJS installation configuration is not persisted to file   
 

  
 
 
 
 

 
 Just to clarify, this isn't just the migration. Even if i delete the 'jenkins.plugins.nodejs.tools.NodeJSInstallation.xml' file, restart jenkins, edit the global tools config, hit save, and restart jenkins the settings are lost. The file 'jenkins.plugins.nodejs.tools.NodeJSInstallation.xml' does not reappear.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41712) NullPointerException when using parameter separator in a pipeline

2017-02-03 Thread jenk...@mockies.de (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Christoph Vogtländer created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41712  
 
 
  NullPointerException when using parameter separator in a pipeline   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 parameter-separator-plugin, pipeline  
 
 
Created: 
 2017/Feb/03 6:24 PM  
 
 
Environment: 
 Jenkins 2.32.2  Pipeline 2.5  Pipeline Groovy 2.25  Parameter Separator 1.0  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Christoph Vogtländer  
 

  
 
 
 
 

 
 Using the parameter separator plug-in in a pipeline job will throw a NullPointerException when accessing global variable "params" 

 

java.lang.NullPointerException
	at org.jenkinsci.plugins.workflow.cps.persistence.IteratorHack.writeReplace(IteratorHack.java:52)
	at org.jenkinsci.plugins.workflow.cps.ParamsVariable.addValue(ParamsVariable.java:88)
	at org.jenkinsci.plugins.workflow.cps.ParamsVariable.getValue(ParamsVariable.java:66)
	at org.jenkinsci.plugins.workflow.cps.CpsScript.getProperty(CpsScript.java:121)
	at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:172)
	at groovy.lang.Closure.getPropertyTryThese(Closure.java:312)
	at groovy.lang.Closure.getPropertyOwnerFirst(Closure.java:306)
	at groovy.lang.Closure.getProperty(Closure.java:295)
	at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:172)
	at groovy.lang.Closure.getPropertyTryThese(Closure.java:312)
	at groovy.lang.Closure.getPropertyOwnerFirst(Closure.java:306)
	at groovy.lang.Closure.getProperty(Closure.java:295)
	at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:172)
	at

[JIRA] (JENKINS-41689) Unable to download S3 artifact from link

2017-02-03 Thread i...@onepost.net (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Marlier commented on  JENKINS-41689  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Unable to download S3 artifact from link   
 

  
 
 
 
 

 
 Seeing the same thing in my configuration. Artifact is properly updated to a bucket in us-west-2, but the resulting links on the Project status page include this query arg: 

 

 X-Amz-Credential=%2F20170203%2Fus-east-1%2Fs3%2Faws4_request
 

 The "us-east-1" in there appears to be hardcoded, and I'm assuming that's the root of the problem.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41659) Stabilise ATH

2017-02-03 Thread cmey...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Cliff Meyers commented on  JENKINS-41659  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Stabilise ATH   
 

  
 
 
 
 

 
 Agree, I don't understand it either. Here's the comment in question: https://github.com/jenkinsci/blueocean-acceptance-test/pull/93#pullrequestreview-15306465 Thorsten Scherler perhaps you can clarify?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41535) NodeJS installation configuration is not persisted to file

Title: Message Title


 
 
 
 

 
 
 

 
   
 Nikolas Falco updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41535  
 
 
  NodeJS installation configuration is not persisted to file   
 

  
 
 
 
 

 
Change By: 
 Nikolas Falco  
 
 
Attachment: 
 migration on Jenkins 2.32.2.png  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-40779) Wiki missing changelog for 1.82 release

2017-02-03 Thread median...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Nick Jones updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-40779  
 
 
  Wiki missing changelog for 1.82 release   
 

  
 
 
 
 

 
Change By: 
 Nick Jones  
 

  
 
 
 
 

 
 The Jenkins wiki at https://wiki.jenkins-ci.org/display/JENKINS/GitHub+API+Plugin does not have entries for any releases since 1.77, and 1. 82 84  is now available.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41535) NodeJS installation configuration is not persisted to file

2017-02-03 Thread tomislav.pasa...@javelingroup.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Nikolas Falco updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41535  
 
 
  NodeJS installation configuration is not persisted to file   
 

  
 
 
 
 

 
Change By: 
 Nikolas Falco  
 
 
Attachment: 
 nodejs.xml  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-28877) Bitbucket Plugin unable to parse Bitbucket webhook response json

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tomislav Pasalic commented on  JENKINS-28877  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Bitbucket Plugin unable to parse Bitbucket webhook response json   
 

  
 
 
 
 

 
 I have this issue as well. Using Jenkins 2.44 and bitbucket plugin 1.1.5. Jenkins receives the payload: 

 

{
	"slug":"XXX",
	"id":94,
	"name":"XXX",
	"scmId":"git",
	"state":"AVAILABLE",
	"statusMessage":"Available",
	"forkable":true,
	"project":{
		"key":"XXX",
		"id":XX,
		"name":"XXX XXX",
		"public":false,
		"type":"NORMAL"
	},
	"public":false
}
 

 And throws the same exception as in description of this ticket with important part being: 

 

Caused by: net.sf.json.JSONException: JSONObject["user"] not found.
 

 Any idea about when this will be fixed or a suggestion of what I may have misconfigured?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options,

[JIRA] (JENKINS-41711) Prevent installation of plugins with unresolvable dependencies

2017-02-03 Thread ryan.campb...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 recampbell updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41711  
 
 
  Prevent installation of plugins with unresolvable dependencies   
 

  
 
 
 
 

 
Change By: 
 recampbell  
 
 
Issue Type: 
 Bug Improvement  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41711) Prevent installation of plugins with unresolvable dependencies

2017-02-03 Thread ryan.campb...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 recampbell created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41711  
 
 
  Prevent installation of plugins with unresolvable dependencies   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 core  
 
 
Created: 
 2017/Feb/03 6:13 PM  
 
 
Labels: 
 robustness  
 
 
Priority: 
  Major  
 
 
Reporter: 
 recampbell  
 

  
 
 
 
 

 
 The update center and setup wizard allows users to install plugins with unresolved dependencies. In this case, the update center meta-data presents a plugin having a dependency which cannot be resolved from any available update center. The user is presently able to install the plugin, but when Jenkins starts up, it will fail to initialize due to the unresolved dependencies. The setupwizard and update center should not allow the user to screw up their installation and thereby protect the user from mistakes or time-delays in publishing dependencies.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-41449) Get lint issues via API call

Title: Message Title


 
 
 
 

 
 
 

 
   
 SCM/JIRA link daemon commented on  JENKINS-41449  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Get lint issues via API call   
 

  
 
 
 
 

 
 Code changed in jenkins User: Victor Martinez Path: .gitignore src/main/java/org/jenkins/ci/plugins/jenkinslint/JenkinsLintAction.java src/main/java/org/jenkins/ci/plugins/jenkinslint/model/AbstractCheck.java src/main/java/org/jenkins/ci/plugins/jenkinslint/model/AbstractSlaveCheck.java src/main/java/org/jenkins/ci/plugins/jenkinslint/model/InterfaceCheck.java src/main/java/org/jenkins/ci/plugins/jenkinslint/model/InterfaceSlaveCheck.java src/main/java/org/jenkins/ci/plugins/jenkinslint/model/Job.java src/main/java/org/jenkins/ci/plugins/jenkinslint/model/Lint.java src/main/java/org/jenkins/ci/plugins/jenkinslint/model/Slave.java src/main/resources/org/jenkins/ci/plugins/jenkinslint/JenkinsLintAction/index.jelly src/test/java/org/jenkins/ci/plugins/jenkinslint/JenkinsLintActionTestCase.java http://jenkins-ci.org/commit/jenkinslint-plugin/dc6f1d1ac0481de9447eb8ce0f5446a225ae7f23 Log: JENKINS-41449 RestAPI feature based on hashes RestAPI feature: creating a list of elements with some hierarchy RestAPI feature: refreshing data when quering through the api otherwise it will keep the previous run which means null when it hasn't been requested through the UI RestAPI feature: fixing bug when creating a list of elements with some hierarchy Deprecated public api and created an alternative one based on Hashes Added some test api cases Added Rest API test cases Excluding evil macosx files Removed wrong size method Using the class name rather than the package+class name, then those data structures amp correctly  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

[JIRA] (JENKINS-41568) Failing to provision new agents despite not being at maxumum

2017-02-03 Thread clgui...@microsoft.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Claudiu Guiman commented on  JENKINS-41568  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Failing to provision new agents despite not being at maxumum   
 

  
 
 
 
 

 
 R. Tyler Croy Is this related to JENKINS-41569 ? Are the ghost provisioned images Windows VMs?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41569) Pipeline hangs waiting for resume on an agent which never was

2017-02-03 Thread clgui...@microsoft.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Claudiu Guiman commented on  JENKINS-41569  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Pipeline hangs waiting for resume on an agent which never was   
 

  
 
 
 
 

 
 What R. Tyler Croy is describing makes sense. Please check why the init script is failing. Jesse Glick you are right. I'll update the plugin so we don't add the node until the init script was completed successful.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-38809) "rbenv build wrapper" disabled after Jenkins restart

2017-02-03 Thread mat...@mathin.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Dan Ebert commented on  JENKINS-38809  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: "rbenv build wrapper" disabled after Jenkins restart   
 

  
 
 
 
 

 
 I am also seeing this issue. Also with the "Unreadable Data" notification in Manage Old Data message. Jenkins version 2.44 rbenv plugin version 0.0.17  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41389) Using multiple "Process Job DSLs" build steps causes UI bugs

2017-02-03 Thread daniel.za...@coremedia.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Daniel Zabel commented on  JENKINS-41389  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using multiple "Process Job DSLs" build steps causes UI bugs   
 

  
 
 
 
 

 
 as workaround for me the following works: 
 
click on "Use the provided DSL script" 
after that click back to "Look on Filesystem", and et voila - the field is displayed again 
  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-40808) Factor Docker fixtures out of acceptance-test-harness for use in functional tests

2017-02-03 Thread jgl...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jesse Glick updated  JENKINS-40808  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-40808  
 
 
  Factor Docker fixtures out of acceptance-test-harness for use in functional tests   
 

  
 
 
 
 

 
Change By: 
 Jesse Glick  
 
 
Status: 
 In Review Resolved  
 
 
Resolution: 
 Fixed  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-40808) Factor Docker fixtures out of acceptance-test-harness for use in functional tests

Title: Message Title


 
 
 
 

 
 
 

 
   
 SCM/JIRA link daemon commented on  JENKINS-40808  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Factor Docker fixtures out of acceptance-test-harness for use in functional tests   
 

  
 
 
 
 

 
 Code changed in jenkins User: Jesse Glick Path: pom.xml src/main/java/org/jenkinsci/test/acceptance/docker/Docker.java src/main/java/org/jenkinsci/test/acceptance/docker/DockerContainer.java src/main/java/org/jenkinsci/test/acceptance/docker/DockerFixture.java src/main/java/org/jenkinsci/test/acceptance/docker/DockerImage.java src/main/java/org/jenkinsci/test/acceptance/docker/DynamicDockerContainer.java src/main/java/org/jenkinsci/test/acceptance/docker/fixtures/JavaContainer.java src/main/java/org/jenkinsci/test/acceptance/docker/fixtures/SshdContainer.java src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/JavaContainer/Dockerfile src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshdContainer/Dockerfile src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshdContainer/unsafe src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshdContainer/unsafe.pub src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshdContainer/unsafe_enc_key src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshdContainer/unsafe_enc_key.pub src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshdContainer/unsafe_enc_key_passphrase.txt src/test/java/org/jenkinsci/test/acceptance/docker/DockerFixtureTest.java src/test/java/org/jenkinsci/test/acceptance/docker/DockerImageTest.java src/test/java/org/jenkinsci/test/acceptance/docker/DynamicDockerContainerTest.java src/test/resources/org/jenkinsci/test/acceptance/docker/DockerFixtureTest/TestContainer/Dockerfile src/test/resources/test/Dockerfile http://jenkins-ci.org/commit/acceptance-test-harness/d682a3da859cc67ea86749642b6b1a102256f25f Log: Merge pull request #252 from jglick/docker-fixtures JENKINS-40808 Using docker-fixtures repository Compare: https://github.com/jenkinsci/acceptance-test-harness/compare/c26b4e0cec68...d682a3da859c  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

[JIRA] (JENKINS-41535) NodeJS installation configuration is not persisted to file

Title: Message Title


 
 
 
 

 
 
 

 
   
 Nikolas Falco assigned an issue to Nikolas Falco  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-41535  
 
 
  NodeJS installation configuration is not persisted to file   
 

  
 
 
 
 

 
Change By: 
 Nikolas Falco  
 
 
Assignee: 
 Nikolas Falco  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41068) Obsolete branch directories are not removed from job directory on master

Title: Message Title


 
 
 
 

 
 
 

 
   
 SCM/JIRA link daemon commented on  JENKINS-41068  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Obsolete branch directories are not removed from job directory on master   
 

  
 
 
 
 

 
 Code changed in jenkins User: Jesse Glick Path: src/main/java/jenkins/branch/MultiBranchProject.java src/test/java/jenkins/branch/WorkspaceLocatorImplTest.java http://jenkins-ci.org/commit/branch-api-plugin/4b47cd42505eacfc85dab4f6d3969866ebef25c8 Log: [FIXED JENKINS-41068] When deleting a branch project, Job.delete’s call to getBuildDir() was forcing MultiBranchProject.getRootDirFor to recreate an empty job directory.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-41535) NodeJS installation configuration is not persisted to file