[JIRA] [display-upstream-changes-plugin] (JENKINS-27048) Multiple upstream projects
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
