[JIRA] [display-upstream-changes-plugin] (JENKINS-27048) Multiple upstream projects

2015-02-21 Thread scm_issue_l...@java.net (JIRA)














































SCM/JIRA link daemon
 commented on  JENKINS-27048


Multiple upstream projects















Code changed in jenkins
User: Rob Petti
Path:
 src/main/java/jenkins/plugins/displayupstreamchanges/DisplayUpstreamChangesSummaryAction.java
http://jenkins-ci.org/commit/display-upstream-changes-plugin/fd7f9994016539d62e1105972fba42adecb19a1c
Log:
  JENKINS-27048 possible fix for issue





























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [matrix-project-plugin] (JENKINS-27066) Matrix project doesn't run all aggregators if one of them throws exception.

2015-02-21 Thread de...@ikedam.jp (JIRA)














































ikedam
 created  JENKINS-27066


Matrix project doesn't run all aggregators if one of them throws exception.















Issue Type:


Improvement



Assignee:


ikedam



Components:


matrix-project-plugin



Created:


22/Feb/15 3:49 AM



Description:


Please consider a project with following publishers in this order:

	A publisher with a bug throwing an exception in its aggregation. (publisher A)
	A publisher sends notification with its aggregation. (publisher B)



In this case, the aggregation of publisher B won't be performed.

Of course, I agree that I should fix the problem in publisher A.
At the same time, I don't think it's useful that a bug in a publisher disables following aggregations. It may prevent notifications from sent to users.

I want matrix-project perform all aggregations even when any of them fail.




Environment:


matrix-project-1.4




Project:


Jenkins



Priority:


Minor



Reporter:


ikedam

























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [bitbucket-oauth-plugin] (JENKINS-27065) Support groups/teams

2015-02-21 Thread di...@plentz.org (JIRA)














































Diego Plentz
 created  JENKINS-27065


Support groups/teams















Issue Type:


Bug



Assignee:


Unassigned


Components:


bitbucket-oauth-plugin



Created:


22/Feb/15 3:19 AM



Description:


It would be great to allow us to use groups when giving users permissions instead of having to set one by one.




Project:


Jenkins



Priority:


Minor



Reporter:


Diego Plentz

























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [jobgenerator-plugin] (JENKINS-21742) Job generator parameters are not resolved correctly for normal build steps

2015-02-21 Thread abubad...@gmail.com (JIRA)












































  
Timm Drevensek
 edited a comment on  JENKINS-21742


Job generator parameters are not resolved correctly for normal build steps
















This is only the case if you are within a Generator Project.

In this project it seems it does not evaluate any Predefined Generator parameters from a Trigger/call builds on other projects step within the Build section.
Workarround is to define Generator Parameters as Job Parameter or to place trigger within the Post-Build action but than you cannot block.

So you cannot generate a project that triggers a parameterized job generator.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [jobgenerator-plugin] (JENKINS-21742) Job generator parameters are not resolved correctly for normal build steps

2015-02-21 Thread abubad...@gmail.com (JIRA)












































  
Timm Drevensek
 edited a comment on  JENKINS-21742


Job generator parameters are not resolved correctly for normal build steps
















This is only the case if you are within a Generator Project.

In this project it seems it does not evaluate any Predefined Generator parameters from a Trigger/call builds on other projects step within the Build section.
Workarround is to define Generator Parameters as Job Parameter or to place trigger within the Post-Build action but than you cannot block.

So you cannot have a generator project, generating a project that triggers a parameterized generator.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [jobgenerator-plugin] (JENKINS-21742) Job generator parameters are not resolved correctly for normal build steps

2015-02-21 Thread abubad...@gmail.com (JIRA)














































Timm Drevensek
 commented on  JENKINS-21742


Job generator parameters are not resolved correctly for normal build steps















It seems it does not evaluate any Predefined Generator parameters from a Trigger/call builds on other projects step within the Build section.
Workarround is to define Generator Parameters as Job Parameter or to place trigger within the Post-Build action but than you cannot block.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [_test] (JENKINS-27064) pusat informasi

2015-02-21 Thread situsiklanmasr...@gmail.com (JIRA)














































mas rooy
 created  JENKINS-27064


pusat informasi















Issue Type:


Bug



Assignee:


mas rooy



Components:


_test



Created:


21/Feb/15 10:39 PM



Project:


Jenkins



Labels:


exception




Priority:


Minor



Reporter:


mas rooy

























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [copy-to-slave-plugin] (JENKINS-25346) "Copy files back to master node" doesn't copy to workspace

2015-02-21 Thread d...@cantab.net (JIRA)














































Dan Jarvis
 commented on  JENKINS-25346


"Copy files back to master node" doesn't copy to workspace















Vivek, the target locations on the master that you described for the Multiconfiguration Project look good to me.  I look forward to testing the new release of the plugin!



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [job-dsl-plugin] (JENKINS-27063) ExtendedEmail Configure Block Behavior

2015-02-21 Thread m...@daniel-spilker.com (JIRA)














































Daniel Spilker
 commented on  JENKINS-27063


ExtendedEmail Configure Block Behavior















https://github.com/jenkinsci/job-dsl-plugin/pull/389



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [job-dsl-plugin] (JENKINS-27063) ExtendedEmail Configure Block Behavior

2015-02-21 Thread m...@daniel-spilker.com (JIRA)














































Daniel Spilker
 created  JENKINS-27063


ExtendedEmail Configure Block Behavior















Issue Type:


Bug



Assignee:


Daniel Spilker



Components:


job-dsl-plugin



Created:


21/Feb/15 8:41 PM



Description:


The configure block of the extendedEmail publisher behaves different than other configure blocks.

In the following example DSL script, the top-level configure block produces different XML than the extendedEmail configure block.


test = 123

job {
  name('foo')
  publishers {
extendedEmail('foo', 'bar') {
  configure {
it / foo(test)
  }
}
  }
  configure {
it / foo(test)
  }
}


The top-level configure block produces 123 whereas the extendedEmail configure block produces test.



...


...
test


...
123






Environment:


Job DSL 1.29




Project:


Jenkins



Priority:


Major



Reporter:


Daniel Spilker

























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [email-ext-plugin] (JENKINS-27062) email-ext-plugin: configurable attachment mime type

2015-02-21 Thread akostadi...@java.net (JIRA)














































akostadinov
 commented on  JENKINS-27062


email-ext-plugin: configurable attachment mime type















Good points. I looked again and it looks my htmls were not generated with proper HTML header and footer. Let me try again with proper HTML and I'll report back.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [email-ext-plugin] (JENKINS-27062) email-ext-plugin: configurable attachment mime type

2015-02-21 Thread akostadi...@java.net (JIRA)












































  
akostadinov
 edited a comment on  JENKINS-27062


email-ext-plugin: configurable attachment mime type
















Good points. I looked again and it appears my htmls were not generated with proper HTML header and footer. Let me try again with proper HTML and I'll report back.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [workflow-plugin] (JENKINS-27039) Option for input step to cancel older executions

2015-02-21 Thread yuriy.kryshc...@gmail.com (JIRA)














































Yuriy Kryshchuk
 commented on  JENKINS-27039


Option for input step to cancel older executions















I would vote for the second solution. 
Right now we have really a case in our build system where we compile ca. 20 projects, the number will increase in the near future.

So if every project will show up several times (like now) as idle build in the dashboard view, that will be a mess. It may have sense to keep those multiple jobs waiting for the user input if the job will appear only once in the dashboard, so that we know yes, there is something to do with that job. 

But still, when we have approved some build for release then very most likely we will not want to release an older build any more, thus it will be a pain to abort all those older builds manually.

Another reason to automatically kill older builds is when there are frequent commints to the build branch. Even during a day we may have the build triggered 10-20 times. When some build gets to the later stage in a pipeline and has already passed all quality criteria which are performed on earlier stages, then it sounds like the newer build is "better" and there is no reason to focus on an older run.

Having the possibility to choose from the multiple builds to proceed with those might be considered as a flexible feature, but for the automated build system it looks more like a drawback as human have to effort in analysing those multiple choices.

While thinking of the actual issue I found another use case that might be better to move to a separate issue: the user input should be eligible to proceed with defaults automatically if user has not reacted during some period of time (of course, that should be a big value on a practice, like few hours or so, and it should be an optional function). Well, you would really allow this kind of automation only if you are super confident in your automated QA in the build workflow.




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [workflow-plugin] (JENKINS-26761) WorkflowJob.getSCMs throws NullPointerException from notifyCommit hooks after Jenkins Restart

2015-02-21 Thread jgl...@cloudbees.com (JIRA)














































Jesse Glick
 commented on  JENKINS-26761


WorkflowJob.getSCMs throws NullPointerException from notifyCommit hooks after Jenkins Restart















See PR 57; could not reproduce from a functional test either.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [workflow-plugin] (JENKINS-26761) WorkflowJob.getSCMs throws NullPointerException from notifyCommit hooks after Jenkins Restart

2015-02-21 Thread jgl...@cloudbees.com (JIRA)















































Jesse Glick
 resolved  JENKINS-26761 as Cannot Reproduce


WorkflowJob.getSCMs throws NullPointerException from notifyCommit hooks after Jenkins Restart
















Was not able to reproduce. Using Linux and Java 8, I ran 1.598 from the WAR with a fresh home directory, installed Workflow plugins (1.2), added the Git plugin (2.3.5), restarted Jenkins to complete the installation. Created a new Git repository /tmp/testrepo, added one file to it and committed. Defined a job



"workflow-job@1.2">
  
  
  false
  
  "org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition" plugin="workflow-cps@1.2">
node {
  git '/tmp/testrepo'
  sh 'ls'
}
false
  
  

  @daily
  false

  



Ran a build; it checked out the repo as expected and listed the one file.

From a shell, ran


$ curl -i http://localhost:8080/jenkins/git/notifyCommit?url=""
HTTP/1.1 200 OK
Triggered: http://localhost:8080/jenkins/job//
Content-Type: text/plain;charset=ISO-8859-1
Content-Length: 92
Server: Jetty(winstone-2.8)

Scheduled polling of 
No Git consumers using SCM API plugin for: /tmp/testrepo


as expected.

Restarted Jenkins (/restart), and when it was back up, ran the same curl command again, with the same result.

Also committed a change to the Git repo and ran the notify command. Again the same curl output, and now build #2 of the job was triggered, with the expected changelog.

If you can still reproduce this problem, please attach $JENKINS_HOME/jobs/$JOBNAME/builds/lastSuccessfulBuild/build.xml. There should be a section beginning


"linked-list">


Your stack trace suggests that it is missing for some reason, but I am not sure how that could have happened.





Change By:


Jesse Glick
(21/Feb/15 6:15 PM)




Status:


In Progress
Resolved





Resolution:


Cannot Reproduce



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [job-dsl-plugin] (JENKINS-22323) job dsl object creation dialect change

2015-02-21 Thread m...@daniel-spilker.com (JIRA)














































Daniel Spilker
 commented on  JENKINS-22323


job dsl object creation dialect change















Pull request: https://github.com/jenkinsci/job-dsl-plugin/pull/388



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [email-ext-plugin] (JENKINS-27062) email-ext-plugin: configurable attachment mime type

2015-02-21 Thread slide.o....@gmail.com (JIRA)














































Alex Earl
 commented on  JENKINS-27062


email-ext-plugin: configurable attachment mime type















That's strange, apparently the MimetypesFileTypeMap.getDefaultFileTypeMap() is returning application/octet-stream for .html. I don't think specifying the content type will happen since attachments are done using patterns. 



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [workflow-plugin] (JENKINS-26761) WorkflowJob.getSCMs throws NullPointerException from notifyCommit hooks after Jenkins Restart

2015-02-21 Thread jgl...@cloudbees.com (JIRA)














































Jesse Glick
 started work on  JENKINS-26761


WorkflowJob.getSCMs throws NullPointerException from notifyCommit hooks after Jenkins Restart
















Change By:


Jesse Glick
(21/Feb/15 5:33 PM)




Status:


Open
In Progress



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [email-ext-plugin] (JENKINS-27062) email-ext-plugin: configurable attachment mime type

2015-02-21 Thread akostadi...@java.net (JIRA)














































akostadinov
 created  JENKINS-27062


email-ext-plugin: configurable attachment mime type















Issue Type:


New Feature



Assignee:


Alex Earl



Components:


email-ext-plugin



Created:


21/Feb/15 4:58 PM



Description:


Hello, using email-ext-plugin and hit a problem. I want to attach an html report to the message but it is attached as 

Content-Type: application/octet-stream; name=report.html


As a result mailers like thunderbird display garbled content (or not at all).

I think it would be very useful to have ability to specify content type of attached files (e.g. text/html).




Project:


Jenkins



Priority:


Minor



Reporter:


akostadinov

























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread gen...@gmail.com (JIRA)












































  
Gennady Feldman
 edited a comment on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin
















The interesting thing is that I am running Jenkins against a GitHub Enterprise instance. So there isn't any rate limit as far as I know. It also uses a dedicated user to access that GitHub instance.


Also not sure why that breaks because of Git Plugin upgrade?



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread gen...@gmail.com (JIRA)














































Gennady Feldman
 commented on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin















The interesting thing is that I am running Jenkins against a GitHub Enterprise instance. So there isn't any rate limit as far as I know. It also uses a dedicated user to access that GitHub instance.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [workflow-plugin] (JENKINS-26605) LogActionImpl/index.jelly misrenders %skipSome

2015-02-21 Thread jgl...@cloudbees.com (JIRA)














































Jesse Glick
 started work on  JENKINS-26605


LogActionImpl/index.jelly misrenders %skipSome
















Change By:


Jesse Glick
(21/Feb/15 3:12 PM)




Status:


Open
In Progress



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [workflow-plugin] (JENKINS-26605) LogActionImpl/index.jelly misrenders %skipSome

2015-02-21 Thread jgl...@cloudbees.com (JIRA)














































Jesse Glick
 commented on  JENKINS-26605


LogActionImpl/index.jelly misrenders %skipSome















Reproducible with this script:


def b = new StringBuilder()
for (int i = 0; i < 1; i++) {
  b.append("line #${i} is really not all that interesting fellows but I am trying to produce a lot of output here\n")
}
echo "${b}"




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [bitbucket-plugin] (JENKINS-27047) Plugin does not work

2015-02-21 Thread bauer.vadim+jenkins...@gmail.com (JIRA)














































Vadimo
 commented on  JENKINS-27047


Plugin does not work















Well this plugin is a brick in swimming pool. At least with jenkins 1.599. IMHO this might be an issue. 



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [workflow-plugin] (JENKINS-26900) Hide flyweight master executor when ≥1 heavyweight executors running as subtasks

2015-02-21 Thread jgl...@cloudbees.com (JIRA)














































Jesse Glick
 updated  JENKINS-26900


Hide flyweight master executor when ≥1 heavyweight executors running as subtasks
















Unfortunately it seems this needs a core API extension, since lib/hudson/executors.jelly does not offer a Queue.Executable a choice of whether it should display a table row, so it does not suffice for WorkflowRun/executorCell.jelly to be an empty .





Change By:


Jesse Glick
(21/Feb/15 2:19 PM)




Labels:


api



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [workflow-plugin] (JENKINS-26900) Hide flyweight master executor when ≥1 heavyweight executors running as subtasks

2015-02-21 Thread jgl...@cloudbees.com (JIRA)














































Jesse Glick
 commented on  JENKINS-26900


Hide flyweight master executor when ≥1 heavyweight executors running as subtasks















if we have the flow idle on user input we still need to see that

Well you would always see at least one task for a running build in the executor widget, from which you can access the input page. (The build history widget shown on the flow’s index page is not affected either.) This is just intended to make simple one-slave flows show only one entry.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [copy-to-slave-plugin] (JENKINS-25346) "Copy files back to master node" doesn't copy to workspace

2015-02-21 Thread svvivekan...@gmail.com (JIRA)














































Vivekanand SV
 commented on  JENKINS-25346


"Copy files back to master node" doesn't copy to workspace















Its okay, I wrote that way for the others to check the output path generated, I wanted to know if they agree to the paths that I am using now for different types of jobs.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread mark.earl.wa...@gmail.com (JIRA)












































  
Mark Waite
 edited a comment on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin
















Gennady Feldman thanks very much for reporting the null pointer exception stack traces. I've reviewed several of them.

One of the stack traces is a good example of what I believe is the common thread through all the null pointer exception cases you reported:


Caused by: java.lang.NullPointerException
at org.jenkinsci.plugins.ghprb.GhprbRepository.getPullRequest(GhprbRepository.java:248)
at org.jenkinsci.plugins.ghprb.GhprbPullRequest.check(GhprbPullRequest.java:169)
at org.jenkinsci.plugins.ghprb.GhprbRepository.onIssueCommentHook(GhprbRepository.java:262)
at org.jenkinsci.plugins.ghprb.GhprbRootAction.doIndex(GhprbRootAction.java:89)

That stack trace (and the 2-3 others that I checked) seem to indicate that the GhprbRepository class has several methods (like this example of getPullRequest(int)) which assume that the GhprbRepository instance being used at that point has called its check() method to initialize the field ghRepository.

Since there is a null pointer exception at this point, I think that must mean that either the check() method was not called (which seems unlikely, since before the upgrade to git plugin 2.3.5 it was working for you), or something inside the check() method call failed, and ghRepository was not initialized (which seems more likely). The current check() method will silently fail to initialize the ghRepository field if gitHub.getRateLimit().remaining is 0.

There may have been a change in the git plugin which causes it to make more calls to GitHub somehow, and thus causes it to reach the rate limit much faster, but I don't recall anything in the changes from 2.3.4 to 2.3.5 which would obviously have caused that. 

Can you attempt the upgrade to 2.3.5 again to see if the rate limit based failure was a coincidental failure and not directly caused by the git plugin upgrade from 2.3.4 to 2.3.5?



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread mark.earl.wa...@gmail.com (JIRA)












































  
Mark Waite
 edited a comment on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin
















Gennady Feldman thanks very much for reporting the null pointer exception stack traces. I've reviewed several of them.

One of the stack traces is a good example of what I believe is the common thread through all the null pointer exception cases you reported:


Caused by: java.lang.NullPointerException
at org.jenkinsci.plugins.ghprb.GhprbRepository.getPullRequest(GhprbRepository.java:248)
at org.jenkinsci.plugins.ghprb.GhprbPullRequest.check(GhprbPullRequest.java:169)
at org.jenkinsci.plugins.ghprb.GhprbRepository.onIssueCommentHook(GhprbRepository.java:262)
at org.jenkinsci.plugins.ghprb.GhprbRootAction.doIndex(GhprbRootAction.java:89)

That stack trace (and the 2-3 others that I checked) seem to indicate that the GhprbRepository class has several methods (like this example of getPullRequest(int)) which assume that the GhprbRepository instance being used at that point has called its check() method to initialize the field ghRepository.

Since there is a null pointer exception at this point, I think that must mean that either the check() method was not called (which seems unlikely, since before the upgrade to git plugin 2.3.5 it was working for you), or something inside the check() method call failed, and ghRepository was not initialized (which seems more likely). The current check() method will silently fail to initialize the ghRepository field if the gitHub.getRateLimit().remaining value is 0. I think that is a reasonable failure, since I assume that when getRateLimit().remaining returns 0, calls to the GitHub API will be disallowed or ignored.

There may have been a change in the git plugin which causes it to make more calls to GitHub somehow, and thus causes it to reach the rate limit much faster, but I don't recall anything in the changes from 2.3.4 to 2.3.5 which would obviously have caused that. 

Can you attempt the upgrade to 2.3.5 again to see if the rate limit based failure was a coincidental failure and not directly caused by the git plugin upgrade from 2.3.4 to 2.3.5?



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [copy-to-slave-plugin] (JENKINS-25346) "Copy files back to master node" doesn't copy to workspace

2015-02-21 Thread dan...@beckweb.net (JIRA)














































Daniel Beck
 commented on  JENKINS-25346


"Copy files back to master node" doesn't copy to workspace















Oh, in that case I just didn't understand what you wrote. So you can interpret my recommendation as agreement to what you wrote.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [copy-to-slave-plugin] (JENKINS-25346) "Copy files back to master node" doesn't copy to workspace

2015-02-21 Thread svvivekan...@gmail.com (JIRA)














































Vivekanand SV
 commented on  JENKINS-25346


"Copy files back to master node" doesn't copy to workspace















Actually, yes. "machine/Lin_Test1/temp_axis/1" and "machine/Lin_Test1/temp_axis/2" parts of the path, from my comment, is generated after checking the prefix 



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [workflow-plugin] (JENKINS-27039) Option for input step to cancel older executions

2015-02-21 Thread jgl...@cloudbees.com (JIRA)














































Jesse Glick
 updated  JENKINS-27039


Option for input step to cancel older executions
















Raising priority since I think this request is useful even in the advertised “CD” demo.





Change By:


Jesse Glick
(21/Feb/15 2:00 PM)




Priority:


Minor
Major



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [workflow-plugin] (JENKINS-27039) Option for input step to cancel older executions

2015-02-21 Thread jgl...@cloudbees.com (JIRA)














































Jesse Glick
 commented on  JENKINS-27039


Option for input step to cancel older executions















Open question what the exact form the option could take. I can think of four possible behaviors, not all of which are necessarily valuable enough to bother implementing and exposing in the UI:


	Current behavior: each input step is independent.
	Kill any older execution when a new input step starts. Thus for a given flow and input id (~ message, by default) there may only be one open prompt at a time.
	Kill any older executions (possibly several) when a newer input step is approved or rejected. Thus the user could choose to approve a build which is not currently the latest, retaining the option to approve subsequent builds which are already waiting for approval.
	Optionally kill older executions upon approval/rejection, but allow the approving/rejecting user to skip that on a case-by-case basis.



The third behavior seems the most useful to me. The second behavior suffers from the problem that a user may spend some time manually vetting a build, only to see it be discarded moments before clicking approval, just because a newer one happened to come in. The fourth behavior seems like it is asking the approver to make a choice that should have been left to the flow designer.

Also “older” vs. “newer” is ambiguous here. The simplest interpretation is by start time, but this could mean that a prompt in an earlier build is considered “newer” than a prompt in a later build, which is probably undesirable from the perspective of a pipeline where later builds are expected to supersede earlier ones. A more useful interpretation is a comparison by build number; this would complicate implementation of the second behavior slightly, since upon entering the step you would not only need to check for other builds which need to be canceled, you would need to check if this build should be canceled.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [copy-to-slave-plugin] (JENKINS-25346) "Copy files back to master node" doesn't copy to workspace

2015-02-21 Thread dan...@beckweb.net (JIRA)














































Daniel Beck
 commented on  JENKINS-25346


"Copy files back to master node" doesn't copy to workspace















Yes, thats what I end up doing as stated in the comment before your reply above.

The approach I describe in that paragraph doesn't require any particular knowledge about matrix axes or matrix projects; it wasn't clear from your comment whether yours does.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread mark.earl.wa...@gmail.com (JIRA)












































  
Mark Waite
 edited a comment on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin
















Gennady Feldman thanks very much for reporting the null pointer exception stack traces. I've reviewed several of them.

One of the stack traces is a good example of what I believe is the common thread through all the null pointer exception cases you reported:


Caused by: java.lang.NullPointerException
at org.jenkinsci.plugins.ghprb.GhprbRepository.getPullRequest(GhprbRepository.java:248)
at org.jenkinsci.plugins.ghprb.GhprbPullRequest.check(GhprbPullRequest.java:169)
at org.jenkinsci.plugins.ghprb.GhprbRepository.onIssueCommentHook(GhprbRepository.java:262)
at org.jenkinsci.plugins.ghprb.GhprbRootAction.doIndex(GhprbRootAction.java:89)

That stack trace (and the 2-3 others that I checked) seem to indicate that the GhprbRepository class has several methods (like this example of getPullRequest(int)) which assume that the GhprbRepository instance being used at that point has called its check() method to initialize the field ghRepository.

Since there is a null pointer exception at this point, I think that must mean that either the check() method was not called (which seems unlikely, since before the upgrade to git plugin 2.3.5 it was working for you), or something inside the check() method call failed, and ghRepository was not initialized (which seems more likely). The current check() method will silently fail to initialize the ghRepository field if the gitHub.getRateLimit().remaining value is 0. I think that is a reasonable failure, since I assume that when getRateLimit().remaining returns 0, calls to the GitHub API will be disallowed or ignored.

There may have been a change in the git plugin which causes it to make more calls to GitHub somehow, and thus causes it to reach the rate limit much faster, but I don't recall anything in the changes from 2.3.4 to 2.3.5 which would obviously have caused that. 

Can you attempt the upgrade to 2.3.5 again to see if the rate limit based failure was a coincidental failure and not directly caused by the git plugin upgrade from 2.3.4 to 2.3.5?



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread mark.earl.wa...@gmail.com (JIRA)












































  
Mark Waite
 edited a comment on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin
















Gennady Feldman thanks very much for reporting the null pointer exception stack traces. I've reviewed several of them.

One of the stack traces is a good example of what I believe is the common thread through all the null pointer exception cases you reported:


Caused by: java.lang.NullPointerException
at org.jenkinsci.plugins.ghprb.GhprbRepository.getPullRequest(GhprbRepository.java:248)
at org.jenkinsci.plugins.ghprb.GhprbPullRequest.check(GhprbPullRequest.java:169)
at org.jenkinsci.plugins.ghprb.GhprbRepository.onIssueCommentHook(GhprbRepository.java:262)
at org.jenkinsci.plugins.ghprb.GhprbRootAction.doIndex(GhprbRootAction.java:89)

That stack trace (and the 2-3 others that I checked) seem to indicate that the GhprbRepository class has several methods (like this example of getPullRequest(int)) which assume that the GhprbRepository instance being used at that point has called its check() method to initialize the field ghRepository.

Since there is a null pointer exception at this point, I think that must mean that either the check() method was not called (which seems unlikely, since before the upgrade to git plugin 2.3.5 it was working for you), or something inside the check() method call failed, and ghRepository was not initialized (which seems more likely). The current check() method will silently fail to initialize the ghRepository field if the gitHub.getRateLimit().remaining value is 0. I think that is a reasonable failure, since I assume that when getRateLimit().remaining returns 0, calls to the GitHub API will be disallowed or ignored.

There may have been a change in the git plugin which causes it to make more calls to GitHub somehow, and thus causes it to cause the rate limit to be reached much faster, but I don't recall anything in the changes from 2.3.4 to 2.3.5 which would obviously have caused that. 

Can you attempt the upgrade to 2.3.5 again to see if the rate limit based failure was a coincidental failure and not directly caused by the git plugin upgrade from 2.3.4 to 2.3.4?



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread mark.earl.wa...@gmail.com (JIRA)












































  
Mark Waite
 edited a comment on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin
















Gennady Feldman thanks very much for reporting the null pointer exception stack traces. I've reviewed several of them.

One of the stack traces is a good example of what I believe is the common thread through all the null pointer exception cases you reported:


Caused by: java.lang.NullPointerException
at org.jenkinsci.plugins.ghprb.GhprbRepository.getPullRequest(GhprbRepository.java:248)
at org.jenkinsci.plugins.ghprb.GhprbPullRequest.check(GhprbPullRequest.java:169)
at org.jenkinsci.plugins.ghprb.GhprbRepository.onIssueCommentHook(GhprbRepository.java:262)
at org.jenkinsci.plugins.ghprb.GhprbRootAction.doIndex(GhprbRootAction.java:89)

That stack trace (and the 2-3 others that I checked) seem to indicate that the GhprbRepository class has several methods (like this example of getPullRequest(int)) which assume that the GhprbRepository instance being used at that point has called its check() method to initialize the field ghRepository.

Since there is a null pointer exception at this point, I think that must mean that either the check() method was not called (which seems unlikely, since before the upgrade to git plugin 2.3.5 it was working for you), or something inside the check() method call failed, and ghRepository was not initialized (which seems more likely). The current check() method will silently fail to initialize the ghRepository field if the gitHub.getRateLimit().remaining value is 0. I think that is a reasonable failure, since I assume that when getRateLimit().remaining returns 0, calls to the GitHub API will be disallowed or ignored.

There may have been a change in the git plugin which causes it to make more calls to GitHub somehow, and thus causes it to cause the rate limit to be reached much faster, but I don't recall anything in the changes from 2.3.4 to 2.3.5 which would obviously have caused that. 

Can you attempt the upgrade to 2.3.5 again to see if the rate limit based failure was a coincidental failure and not directly caused by the git plugin upgrade from 2.3.4 to 2.3.5?



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread mark.earl.wa...@gmail.com (JIRA)












































  
Mark Waite
 edited a comment on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin
















Gennady Feldman thanks very much for reporting the null pointer exception stack traces. I've reviewed several of them.

One of the stack traces is a good example of what I believe is the common thread through all the null pointer exception cases you reported:


Caused by: java.lang.NullPointerException
at org.jenkinsci.plugins.ghprb.GhprbRepository.getPullRequest(GhprbRepository.java:248)
at org.jenkinsci.plugins.ghprb.GhprbPullRequest.check(GhprbPullRequest.java:169)
at org.jenkinsci.plugins.ghprb.GhprbRepository.onIssueCommentHook(GhprbRepository.java:262)
at org.jenkinsci.plugins.ghprb.GhprbRootAction.doIndex(GhprbRootAction.java:89)

(and the 2-3 others that I checked) seem to indicate that the GhprbRepository class has several methods (like this example of getPullRequest(int)) which assume that the GhprbRepository instance being used at that point has called its check() method to initialize the field ghRepository.

Since there is a null pointer exception at this point, I think that must mean that either the check() method was not called (which seems unlikely, since before the upgrade to git plugin 2.3.5 it was working for you), or something inside the check() method call failed, and ghRepository was not initialized (which seems more likely). The current check() method will silently fail to initialize the ghRepository field if the gitHub.getRateLimit().remaining value is 0. I think that is a reasonable failure, since I assume that when getRateLimit().remaining returns 0, calls to the GitHub API will be disallowed or ignored.

There may have been a change in the git plugin which causes it to make more calls to GitHub somehow, and thus causes it to cause the rate limit to be reached much faster, but I don't recall anything in the changes from 2.3.4 to 2.3.5 which would obviously have caused that. 

Can you attempt the upgrade to 2.3.5 again to see if the rate limit based failure was a coincidental failure and not directly caused by the git plugin upgrade from 2.3.4 to 2.3.4?



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread mark.earl.wa...@gmail.com (JIRA)












































  
Mark Waite
 edited a comment on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin
















Gennady Feldman thanks very much for reporting the null pointer exception stack traces. I'm reviewing them now.

Caused by: java.lang.NullPointerException
at org.jenkinsci.plugins.ghprb.GhprbRepository.getPullRequest(GhprbRepository.java:248)
at org.jenkinsci.plugins.ghprb.GhprbPullRequest.check(GhprbPullRequest.java:169)
at org.jenkinsci.plugins.ghprb.GhprbRepository.onIssueCommentHook(GhprbRepository.java:262)
at org.jenkinsci.plugins.ghprb.GhprbRootAction.doIndex(GhprbRootAction.java:89)

(and the 2-3 others that I checked) seem to indicate that the GhprbRepository class has several methods (like this example of getPullRequest(int)) which assume that the GhprbRepository instance being used at that point has called its check() method to initialize the field ghRepository.

Since there is a null pointer exception at this point, I think that must mean that either the check() method was not called (which seems unlikely, since before the upgrade to git plugin 2.3.5 it was working for you), or something inside the check() method call failed, and ghRepository was not initialized (which seems more likely). The current check() method will silently fail to initialize the ghRepository field if the gitHub.getRateLimit().remaining value is 0. I think that is a reasonable failure, since I assume that when getRateLimit().remaining returns 0, calls to the GitHub API will be disallowed or ignored.

There may have been a change in the git plugin which causes it to make more calls to GitHub somehow, and thus causes it to cause the rate limit to be reached much faster, but I don't recall anything in the changes from 2.3.4 to 2.3.5 which would obviously have caused that. 

Can you attempt the upgrade to 2.3.5 again to see if the rate limit based failure was a coincidental failure and not directly caused by the git plugin upgrade from 2.3.4 to 2.3.4?



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread mark.earl.wa...@gmail.com (JIRA)












































  
Mark Waite
 edited a comment on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin
















Gennady Feldman thanks very much for reporting the null pointer exception stack traces. I'm reviewing them now.


Caused by: java.lang.NullPointerException
at org.jenkinsci.plugins.ghprb.GhprbRepository.getPullRequest(GhprbRepository.java:248)
at org.jenkinsci.plugins.ghprb.GhprbPullRequest.check(GhprbPullRequest.java:169)
at org.jenkinsci.plugins.ghprb.GhprbRepository.onIssueCommentHook(GhprbRepository.java:262)
at org.jenkinsci.plugins.ghprb.GhprbRootAction.doIndex(GhprbRootAction.java:89)

(and the 2-3 others that I checked) seem to indicate that the GhprbRepository class has several methods (like this example of getPullRequest(int)) which assume that the GhprbRepository instance being used at that point has called its check() method to initialize the field ghRepository.

Since there is a null pointer exception at this point, I think that must mean that either the check() method was not called (which seems unlikely, since before the upgrade to git plugin 2.3.5 it was working for you), or something inside the check() method call failed, and ghRepository was not initialized (which seems more likely). The current check() method will silently fail to initialize the ghRepository field if the gitHub.getRateLimit().remaining value is 0. I think that is a reasonable failure, since I assume that when getRateLimit().remaining returns 0, calls to the GitHub API will be disallowed or ignored.

There may have been a change in the git plugin which causes it to make more calls to GitHub somehow, and thus causes it to cause the rate limit to be reached much faster, but I don't recall anything in the changes from 2.3.4 to 2.3.5 which would obviously have caused that. 

Can you attempt the upgrade to 2.3.5 again to see if the rate limit based failure was a coincidental failure and not directly caused by the git plugin upgrade from 2.3.4 to 2.3.4?



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread mark.earl.wa...@gmail.com (JIRA)












































  
Mark Waite
 edited a comment on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin
















Gennady Feldman thanks very much for reporting the null pointer exception stack traces. I'm reviewing them now.

Caused by: java.lang.NullPointerException
at org.jenkinsci.plugins.ghprb.GhprbRepository.getPullRequest(GhprbRepository.java:248)
at org.jenkinsci.plugins.ghprb.GhprbPullRequest.check(GhprbPullRequest.java:169)
at org.jenkinsci.plugins.ghprb.GhprbRepository.onIssueCommentHook(GhprbRepository.java:262)
at org.jenkinsci.plugins.ghprb.GhprbRootAction.doIndex(GhprbRootAction.java:89)

(and the 2-3 others that I checked) seem to indicate that the GhprbRepository class has several methods (like this example of getPullRequest(int)) which assume that the GhprbRepository instance being used at that point has called its check() method to initialize the field ghRepository.

Since there is a null pointer exception at this point, I think that must mean that either the check() method was not called (which seems unlikely, since before the upgrade to git plugin 2.3.5 it was working for you), or something inside the check() method call failed, and ghRepository was not initialized (which seems more likely). The current check() method will silently fail to initialize the ghRepository field if the gitHub.getRateLimit().remaining value is 0. I think that is a reasonable failure, since I assume that when getRateLimit().remaining returns 0, calls to the GitHub API will be disallowed or ignored.

There may have been a change in the git plugin which causes it to make more calls to GitHub somehow, and thus causes it to cause the rate limit to be reached much faster, but I don't recall anything in the changes from 2.3.4 to 2.3.5 which would obviously have caused that. 

Can you attempt the upgrade to 2.3.5 again to see if the rate limit based failure was a coincidental failure and not directly caused by the git plugin upgrade from 2.3.4 to 2.3.4?



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread mark.earl.wa...@gmail.com (JIRA)












































  
Mark Waite
 edited a comment on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin
















Gennady Feldman thanks very much for reporting the null pointer exception stack traces. I'm reviewing them now.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ghprb-plugin] (JENKINS-27056) Latest Git Plugin breaks ghprb-plugin

2015-02-21 Thread mark.earl.wa...@gmail.com (JIRA)














































Mark Waite
 commented on  JENKINS-27056


Latest Git Plugin breaks ghprb-plugin















Gennady Feldman thanks very much for reporting the null pointer exception. I'm reviewing it now.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [copy-to-slave-plugin] (JENKINS-25346) "Copy files back to master node" doesn't copy to workspace

2015-02-21 Thread svvivekan...@gmail.com (JIRA)














































Vivekanand SV
 commented on  JENKINS-25346


"Copy files back to master node" doesn't copy to workspace















What you could try is to determine the TopLevelItem ancestor of the current build's project, and get the workspace of that on the current node (e.g. /jenkins/workspace/foo). If that's a prefix of the current actual workspace (/jenkins/workspace/foo/bar/baz), just append the rest (/bar/baz) to the workspace path on master

Yes, thats what I end up doing as stated in the comment before your reply above.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [copy-to-slave-plugin] (JENKINS-25346) "Copy files back to master node" doesn't copy to workspace

2015-02-21 Thread dan...@beckweb.net (JIRA)














































Daniel Beck
 commented on  JENKINS-25346


"Copy files back to master node" doesn't copy to workspace















@Daniel, getWorkspaceFor() accepts only an implementation of TopLevelItem, so this will work in case of a free style project, what about other cases ? I tried Jenkins javadoc for some time but I couldn't get a clue.

All projects generally are top-level items. It won't cover matrix axes and similar cases though, where project types divide their workspaces further.

What you could try is to determine the TopLevelItem ancestor of the current build's project, and get the workspace of that on the current node (e.g. /jenkins/workspace/foo). If that's a prefix of the current actual workspace (/jenkins/workspace/foo/bar/baz), just append the rest (/bar/baz) to the workspace path on master

It seems to me that the design of this feature is broken if you need to know about details like that, and an approximation and/or specifically adding support for job types is the best you can do.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [remoting] (JENKINS-27046) Restarted the master and all slaves went offline

2015-02-21 Thread dan...@beckweb.net (JIRA)














































Daniel Beck
 updated  JENKINS-27046


Restarted the master and all slaves went offline
















Change By:


Daniel Beck
(21/Feb/15 12:07 PM)




Component/s:


remoting





Component/s:


core



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [core] (JENKINS-26298) Console output does not scroll anymore

2015-02-21 Thread dan...@beckweb.net (JIRA)














































Daniel Beck
 commented on  JENKINS-26298


Console output does not scroll anymore















Please file a new issue, the behavior you describe has nothing at all to do with this report.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [gitlab-hook-plugin] (JENKINS-24230) allow build projects to be specified

2015-02-21 Thread javier.palac...@fon.com (JIRA)














































Javier Palacios
 commented on  JENKINS-24230


allow build projects to be specified















Hello Adrian, recently released 1.3.0 version allows automatic project creation when no existing project matches the incoming payload. Does this functionality match your needs in some manner?
I don't know what you mean by 'templates', but I guess you are using the same Jenkins project to build multiple repositories and/or branches, passing the git_url & branch as parameters. If that is the case, the latest release will probably help you, unless you specifically want having a single Jenkins project for multiple repositories, in which case you might have a look anyway to the multi-scm capabilities released with 1.2.1.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [gitlab-hook-plugin] (JENKINS-24232) Hook fails on parametrized jobs

2015-02-21 Thread javier.palac...@fon.com (JIRA)















































Javier Palacios
 closed  JENKINS-24232 as Fixed


Hook fails on parametrized jobs
















Change By:


Javier Palacios
(21/Feb/15 11:21 AM)




Status:


Resolved
Closed



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [gitlab-hook-plugin] (JENKINS-24403) Cannot create jobs for branches under ldap authentication

2015-02-21 Thread javier.palac...@fon.com (JIRA)















































Javier Palacios
 closed  JENKINS-24403 as Fixed


Cannot create jobs for branches under ldap authentication
















Change By:


Javier Palacios
(21/Feb/15 11:19 AM)




Status:


Resolved
Closed



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ircbot-plugin] (JENKINS-13558) should support server password

2015-02-21 Thread ku...@gmx.de (JIRA)














































kutzi
 reopened  JENKINS-13558


should support server password
















Change By:


kutzi
(21/Feb/15 10:07 AM)




Resolution:


Won't Fix





Status:


Resolved
Reopened



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ircbot-plugin] (JENKINS-13558) should support server password

2015-02-21 Thread ku...@gmx.de (JIRA)















































kutzi
 closed  JENKINS-13558 as Fixed


should support server password
















Change By:


kutzi
(21/Feb/15 10:07 AM)




Status:


Resolved
Closed



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [ircbot-plugin] (JENKINS-13558) should support server password

2015-02-21 Thread ku...@gmx.de (JIRA)















































kutzi
 resolved  JENKINS-13558 as Fixed


should support server password
















Change By:


kutzi
(21/Feb/15 10:07 AM)




Status:


Reopened
Resolved





Resolution:


Fixed



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [instant-messaging-plugin] (JENKINS-26892) With concurrent builds, IRC Notification blocks later builds from finishing first

2015-02-21 Thread s...@flanigan.org (JIRA)














































Sean Flanigan
 commented on  JENKINS-26892


With concurrent builds, IRC Notification blocks later builds from finishing first















Great, thank you!



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [copy-to-slave-plugin] (JENKINS-25346) "Copy files back to master node" doesn't copy to workspace

2015-02-21 Thread svvivekan...@gmail.com (JIRA)














































Vivekanand SV
 commented on  JENKINS-25346


"Copy files back to master node" doesn't copy to workspace















@ Aaron, @Dan, @Daniel ... I fixed this and have the changes ready for release, before I release I need your feedback on the paths I chose (asking you people as you might have some real use-cases which can help me decide this)

Assuming the following factors, 

Multiconfiguration Project name - C2S_Test_MultiConf
Axis 1 label - machine
Axis 1 Label values  - Lin_Test1 and master

Axis 2 label - temp_axis
Axis 2 label values  - 1 and 2

the files copied on the master will be @
/home/test/jenkins/workspace/C2S_Test_MultiConf/machine/Lin_Test1/temp_axis/1  
/home/test/jenkins/workspace/C2S_Test_MultiConf/machine/Lin_Test1/temp_axis/2

other machine is master itself, so they wont be copied.

I thought of copying the files into "/home/test/jenkins/workspace/C2S_Test_MultiConf/" itself, but i was thinking these files should be kept separate for each configuration.

For freestyle job, workspace will be the default one "/home/test/jenkins/workspace/C2S_Test_FreeStyle/" where "C2S_Test_FreeStyle" is the project name.

Coming to Maven style jobs, if you guys can give me example paths I can add that for those.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [instant-messaging-plugin] (JENKINS-26892) With concurrent builds, IRC Notification blocks later builds from finishing first

2015-02-21 Thread ku...@gmx.de (JIRA)















































kutzi
 resolved  JENKINS-26892 as Fixed


With concurrent builds, IRC Notification blocks later builds from finishing first
















Fixed in 2.26





Change By:


kutzi
(21/Feb/15 9:24 AM)




Status:


Open
Resolved





Resolution:


Fixed



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [workflow-plugin] (JENKINS-26987) Hiding certain steps from the "Running Steps" tree

2015-02-21 Thread ert...@gmail.com (JIRA)














































Timur Batyrshin
 commented on  JENKINS-26987


Hiding certain steps from the "Running Steps" tree















But text console produces intermixed output of the parallel builds. It's quite challenging to separate the text from different branches in the combined console output.



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
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] [scm-sync-configuration-plugin] (JENKINS-26727) SCM Sync not triggering when saving jobs

2015-02-21 Thread the...@java.net (JIRA)














































thedug
 commented on  JENKINS-26727


SCM Sync not triggering when saving jobs















Is anybody else seeing this? Is there a work around?



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







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