[JIRA] [matrix-project-plugin] (JENKINS-25604) MatrixConfiguration.useShortWorkspaceName does not alter the workspace path
Oliver Gondža resolved JENKINS-25604 as Cannot Reproduce MatrixConfiguration.useShortWorkspaceName does not alter the workspace path All bogus, it works like a charm. Change By: Oliver Gondža (14/Nov/14 7:39 AM) Status: Open Resolved Assignee: Kohsuke Kawaguchi Oliver Gondža 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] [credentials-plugin] (JENKINS-25612) Add PropertyFileCredentials provider
Oleg Nenashev assigned JENKINS-25612 to Oleg Nenashev Add PropertyFileCredentials provider Change By: Oleg Nenashev (14/Nov/14 7:39 AM) Assignee: stephenconnolly Oleg Nenashev 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] [credentials-plugin] (JENKINS-25612) Add PropertyFileCredentials provider
Oleg Nenashev created JENKINS-25612 Add PropertyFileCredentials provider Issue Type: New Feature Assignee: stephenconnolly Components: credentials-plugin Created: 14/Nov/14 7:39 AM Description: Use-cases for StandardUsernamePasswordCredentials coming from property files: Usage of local credential files stored on Jenkins Server (e.g. .github file being used in github-api) Using credentials from URL The implementation must notify users that the implementation is not secure and they take the full responsibility. Project: Jenkins Priority: Minor Reporter: Oleg Nenashev 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] [credentials-plugin] (JENKINS-25612) Add PropertyFileCredentials provider
Oleg Nenashev started work on JENKINS-25612 Add PropertyFileCredentials provider Change By: Oleg Nenashev (14/Nov/14 7:39 AM) 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] [perforce-plugin] (JENKINS-25611) Unable to save "Use View Mask/Use mask when determining changelog" only
Rob Petti assigned JENKINS-25611 to Oleg Nenashev Unable to save "Use View Mask/Use mask when determining changelog" only Oleg it seems the view mask settings are not saving. Change By: Rob Petti (14/Nov/14 3:44 AM) Assignee: Rob Petti Oleg Nenashev 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] [gerrit-trigger-plugin] (JENKINS-20897) Wrong encoding of characters (e.g. æøå) in commit messages, committers name, etc
rin_ne commented on JENKINS-20897 Wrong encoding of characters (e.g. æøå) in commit messages, committers name, etc Maybe this patch will fix https://github.com/sonyxperiadev/gerrit-events/pull/28 Not sure release plan. 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] [perforce-plugin] (JENKINS-25611) Unable to save "Use View Mask/Use mask when determining changelog" only
xster created JENKINS-25611 Unable to save "Use View Mask/Use mask when determining changelog" only Issue Type: Bug Assignee: Rob Petti Attachments: CheckDisappear.PNG Components: perforce-plugin Created: 14/Nov/14 2:18 AM Description: Check "Use View Mask" Check "Use mask when polling" (checked by default) Not check "Use mask when syncing" Check "Use mask when determining changelog" After restart Check for "Use mask when determining changelog" disappears Environment: Jenkins ver.1.542 Perforce plugin 1.3.27 Project: Jenkins Labels: plugin Priority: Minor Reporter: xster 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] [unity3d-plugin] (JENKINS-25610) unity 4.6
takumi hatta closed JENKINS-25610 as Won't Fix unity 4.6 Change By: takumi hatta (14/Nov/14 2:02 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] [unity3d-plugin] (JENKINS-25610) unity 4.6
takumi hatta updated JENKINS-25610 unity 4.6 Change By: takumi hatta (14/Nov/14 2:00 AM) Description: hi.I would like you to add new version of unity（4.6b, rc0） if you have time, please add it... 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] [unity3d-plugin] (JENKINS-25610) unity 4.6
takumi hatta resolved JENKINS-25610 as Won't Fix unity 4.6 Change By: takumi hatta (14/Nov/14 1:58 AM) Status: Open Resolved Resolution: Won't Fix 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] [unity3d-plugin] (JENKINS-25610) unity 4.6
takumi hatta created JENKINS-25610 unity 4.6 Issue Type: New Feature Assignee: lacostej Components: unity3d-plugin Created: 14/Nov/14 1:56 AM Description: hi. I would like you to add new version of unity（4.6b, rc0） if you have time, please add it... Project: Jenkins Priority: Blocker Reporter: takumi hatta 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-25609) Build Queue is not being processed! Jobs Queueing up....
Phil Rumble created JENKINS-25609 Build Queue is not being processed! Jobs Queueing up Issue Type: Bug Assignee: Unassigned Attachments: catalina.2014-11-14.log Components: core Created: 14/Nov/14 1:22 AM Description: The build queue builds up and there are plenty of executors available on several nodes as well as the master node. The system memory usage is quite low < 2Gb (system has > 16Gb) The log file is full of entries like Nov 14, 2014 9:09:21 AM hudson.triggers.SafeTimerTask run SEVERE: Timer task hudson.model.Queue$MaintainTask@c2f8092d failed java.lang.IllegalThreadStateException: Thread is already started at java.lang.Thread.start(Thread.java:953) at hudson.model.Executor.start(Executor.java:497) at hudson.model.Queue$JobOffer.set(Queue.java:261) at hudson.model.queue.MappingWorksheet$ExecutorChunk.execute(MappingWorksheet.java:164) at hudson.model.queue.MappingWorksheet$ExecutorChunk.access$000(MappingWorksheet.java:112) at hudson.model.queue.MappingWorksheet$Mapping.execute(MappingWorksheet.java:313) at hudson.model.Queue.maintain(Queue.java:1064) at hudson.model.Queue$MaintainTask.doRun(Queue.java:2033) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:482) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:315) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:193) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:308) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1176) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.lang.Thread.run(Thread.java:795) Environment: jenkinss 1.580.1 Red Hat Enterprise Linux Server release 6.5 (Santiago) Linux Jenkins 2.6.32-431.29.2.el6.x86_64 #1 SMP Sun Jul 27 15:55:46 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux running jenkins in tomcat 6 (tomcat6-6.0.24-78.el6_5) running with java 1.7 java -version java version "1.7.0" Java(TM) SE Runtime Environment (build pxa6470sr7fp1-20140708_01(SR7 FP1)) IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 Compressed References 20140627_204598 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR7_20140627_0924_B204598 JIT - r11.b06_20140409_61252.04 GC - R26_Java726_SR7_20140627_0924_B204598_CMPRSS J9CL - 20140627_204598) JCL - 20140707_01 based on Oracle 7u65-b16 Project: Jenkins Priority: Blocker Reporter: Phil Rumble 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] [git-plugin] (JENKINS-25580) Git plugin polls incorrect branch
Nathan Gray commented on JENKINS-25580 Git plugin polls incorrect branch It's your plugin and you can do whatever you want, but if there's somebody out there who's relying on a branch spec of "remoteName/bar/baz" to build "bar/baz" but match a randomly selected branch ending in "baz" for polling then they are seriously deranged. There is no rational use for this behavior. It's a good and noble thing to provide stability and compatibility for your users, but locking in senseless bugs is just pouring cement around your own feet. If you really must keep this bizarre behavior (which is completely different from the way git branch names work in every other context outside your plugin) you really should do more to document it. The current documentation says this: / Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily the expected one. Better use refs/heads/. E.g. origin/master This is only partially true. The branch I specified was unambiguous and worked fine for building but caused polling to fail. In fact, it takes the last "path" component of the branch and uses that, but only for polling it would appear. Good luck trying to explain that. Your best bet is probably to just display a bright red warning if the branch spec doesn't start with one of your "good" prefixes. RE your question, the version that worked was a 1.x version. I'm not sure exactly which because we went through a few 2.x versions trying to debug this polling problem. 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] [artifactory-plugin] (JENKINS-25590) Artifactory plugin is not deploying when there is cobertura:cobertura goal
Wisen Tanasa closed JENKINS-25590 as Won't Fix Artifactory plugin is not deploying when there is cobertura:cobertura goal Not a good practice to combine both of this plugins in 1 job. Closing issue. Change By: Wisen Tanasa (14/Nov/14 12:09 AM) Status: Open Closed Resolution: Won't Fix 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] [git-plugin] (JENKINS-25580) Git plugin polls incorrect branch
Mark Waite edited a comment on JENKINS-25580 Git plugin polls incorrect branch Whether we use git rev-parse or some other form, we still have the compatibility problem. The unfortunate definition of that field is that it takes the text from the right of the rightmost slash and uses that as the branch name. I wish it didn't do that, but that is what it does. With over 40 000 installations of the git plugin, I'm confident there are many cases where that behavior is crucial to their use of the plugin. I can't justify breaking their use of the plugin to resolve my concern that the branch specification they used is not doing the right thing. Users (like you and me) who need more precise (or accurate) specification of the branch name can either use the refs/heads syntax or can use a regular _expression_ to define the branch to build. Both are described in the help. and both are available for use, without breaking compatibility for existing users. Those existing users may just be "lucky" that the current behavior is what they want, but even if they are just "lucky", they will be dissatisfied if the behavior changes. Note that this is a regression from the last version of the plugin I used, where "origin/release/flow" did the right thing. I'm not asking for new behavior, I'm asking for previously working branch names to work again. Which version of the git plugin did the right thing with "origin/release/flow"? I haven't investigated the entire history of the git plugin, but as far as I know, the plugin has behaved this way since at least git plugin 2.0. 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] [git-plugin] (JENKINS-25580) Git plugin polls incorrect branch
Mark Waite commented on JENKINS-25580 Git plugin polls incorrect branch Whether we use git rev-parse or some other form, we still have the compatibility problem. The unfortunate definition of that field is that it takes the text from the right of the rightmost slash and uses that as the branch name. I wish it didn't do that, but that is what it does. With over 40 000 installations of the git plugin, I'm confident there are many cases where that behavior is crucial to their use of the plugin. I can't justify breaking their use of the plugin to resolve my concern that the branch specification they used is not doing the right thing. Users (like you and me) who need more precise (or accurate) specification of the branch name can either use the refs/heads syntax or can use a regular _expression_ to define the branch to build. Both are described in the help. and both are available for use, without breaking compatibility for existing users. Those existing users may just be "lucky" that the current behavior is what they want, but even if they are just "lucky", they will be dissatisfied if the behavior changes. > Note that this is a regression from the last version of the plugin I used, where "origin/release/flow" did the right thing. I'm not asking for new behavior, I'm asking for previously working branch names to work again. Which version of the git plugin did the right thing with "origin/release/flow"? I haven't investigated the entire history of the git plugin, but as far as I know, the plugin has behaved this way since at least git plugin 2.0. 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-21621) bad path environment set by Jenkins
Oleg Nenashev resolved JENKINS-21621 as Duplicate bad path environment set by Jenkins Yes, it's a duplicate. BTW, the name of the old issue is not good Change By: Oleg Nenashev (13/Nov/14 11:40 PM) Status: Open Resolved Resolution: Duplicate 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] [plugin-proposals] (JENKINS-24353) "UI Themes" plugin
Oleg Nenashev assigned JENKINS-24353 to Tom FENNELLY "UI Themes" plugin Change By: Oleg Nenashev (13/Nov/14 11:30 PM) Assignee: Tom FENNELLY 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] [plugin-proposals] (JENKINS-24353) "UI Themes" plugin
Oleg Nenashev started work on JENKINS-24353 "UI Themes" plugin Change By: Oleg Nenashev (13/Nov/14 11:29 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] [plugin-proposals] (JENKINS-24353) "UI Themes" plugin
Oleg Nenashev commented on JENKINS-24353 "UI Themes" plugin @Tom As I see, you have already released https://github.com/jenkinsci/uithemes-plugin Do you have any plans on Wiki pages and other such stuff? 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] [plugin-proposals] (JENKINS-24353) "UI Themes" plugin
Oleg Nenashev updated JENKINS-24353 "UI Themes" plugin Change By: Oleg Nenashev (13/Nov/14 11:28 PM) Component/s: plugin-proposals 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-24374) java.util.zip.ZipException thrown when starting Jenkins using >mvn hpi:run
Oleg Nenashev assigned JENKINS-24374 to Scott Hathaway java.util.zip.ZipException thrown when starting Jenkins using >mvn hpi:run Change By: Oleg Nenashev (13/Nov/14 11:25 PM) Assignee: Scott Hathaway 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-24374) java.util.zip.ZipException thrown when starting Jenkins using >mvn hpi:run
Oleg Nenashev started work on JENKINS-24374 java.util.zip.ZipException thrown when starting Jenkins using >mvn hpi:run Change By: Oleg Nenashev (13/Nov/14 11:24 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] [core] (JENKINS-21143) Timezone override by user
Oleg Nenashev resolved JENKINS-21143 as Duplicate Timezone override by user Duplicates JENKINS-19887 Change By: Oleg Nenashev (13/Nov/14 11:21 PM) Status: Open Resolved Resolution: Duplicate 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] [gerrit-trigger-plugin] (JENKINS-25608) Intermittent gerrit trigger NPE on Jenkins restart
Carter Sanders commented on JENKINS-25608 Intermittent gerrit trigger NPE on Jenkins restart When I say "does not work" I mean gerrit events are not detected by jenkins and jenkins is unable to post build success/fail to gerrit. 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] [gerrit-trigger-plugin] (JENKINS-25608) Intermittent gerrit trigger NPE on Jenkins restart
Carter Sanders created JENKINS-25608 Intermittent gerrit trigger NPE on Jenkins restart Issue Type: Bug Assignee: rsandell Components: gerrit-trigger-plugin Created: 13/Nov/14 11:18 PM Description: On a very overloaded jenkins server (>1K jobs, some jobs have more then 10K job history), on reboot, the gerrit and jenkins association often does not work. When this occurs, the following exception is seen in the jenkins log- Nov 11, 2014 7:20:08 PM com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler notifyListener SEVERE: Exception thrown during event handling. java.lang.NullPointerException at com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTrigger.gerritEvent(GerritTrigger.java:443) at com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler.notifyListener(GerritHandler.java:318) at com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler.notifyListeners(GerritHandler.java:290) at com.sonyericsson.hudson.plugins.gerrit.gerritevents.workers.AbstractGerritEventWork.perform(AbstractGerritEventWork.\ java:45) at com.sonyericsson.hudson.plugins.gerrit.gerritevents.workers.GerritEventWork.perform(GerritEventWork.java:47) at com.sonyericsson.hudson.plugins.gerrit.gerritevents.workers.EventThread.run(EventThread.java:65) Environment: Jenkins ver. 1.565.3 Ubuntu 12.04.4 LTS Gerrit Trigger 2.11.1 Gerrit 2.8.5 Project: Jenkins Priority: Minor Reporter: Carter Sanders 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] [groovy-plugin] (JENKINS-25392) Post Build Steps still running regardless of Pre Step Groovy Script failure
vjuranek commented on JENKINS-25392 Post Build Steps still running regardless of Pre Step Groovy Script failure Hi, I wrote a test which verifies that build fails when exception is thrown from groovy script. Test is passing, so IMHO this is really not an issue in groovy plugin itself, but in a component which wraps groovy script (and probably ignores error status of groovy step). 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] [xshell-plugin] (JENKINS-25600) XShell does not kill running process if job is getting aborted
Henrik Skupin commented on JENKINS-25600 XShell does not kill running process if job is getting aborted That's correct. Via the red button as visible in the console output in the top right, or in the node list in the dashboard. 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] [xshell-plugin] (JENKINS-25600) XShell does not kill running process if job is getting aborted
Jeremy Marshall commented on JENKINS-25600 XShell does not kill running process if job is getting aborted So you're killing the build through Jenkins, rather than it timing out? 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-import-plugin] (JENKINS-24184) "Password/API Token" box in clear text
Raphaël UNIQUE commented on JENKINS-24184 "Password/API Token" box in clear text Hello, when will this fix be released? 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] [buildresult-trigger-plugin] (JENKINS-25216) Build Triggers: Option "Build whenever a SNAPSHOT dependency is built" does not work properly
Alexander Wolff commented on JENKINS-25216 Build Triggers: Option "Build whenever a SNAPSHOT dependency is built" does not work properly You should change this issue from buildresult-trigger-plugin to maven-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] [buildresult-trigger-plugin] (JENKINS-25216) Build Triggers: Option "Build whenever a SNAPSHOT dependency is built" does not work properly
Alexander Wolff edited a comment on JENKINS-25216 Build Triggers: Option "Build whenever a SNAPSHOT dependency is built" does not work properly It seems that the behaviour is not a bug. Downstream projects are only scheduled if the current project is built successfully. Looking at hudson.maven.AbstractMavenProject.java in Jenkins maven-plugin, this issue is almost resolved in the logic. There is a condition in shouldTriggerBuild() to return immediately if build result doesn't meet Result#SUCCESS. In my opinion the condition should be configurable like post build actions. 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] [buildresult-trigger-plugin] (JENKINS-25216) Build Triggers: Option "Build whenever a SNAPSHOT dependency is built" does not work properly
Alexander Wolff edited a comment on JENKINS-25216 Build Triggers: Option "Build whenever a SNAPSHOT dependency is built" does not work properly It seems that the behaviour is not a bug. Downstream projects are only scheduled if the current project is built successfully. Looking at hudson.maven.AbstractMavenProject.java in Jenkins maven-plugin, this issue is almost resolved in the logic. There is a condition in shouldTriggerBuild() to return immediately if build result doesn't meet Result#SUCCESS. 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] [buildresult-trigger-plugin] (JENKINS-25216) Build Triggers: Option "Build whenever a SNAPSHOT dependency is built" does not work properly
Alexander Wolff edited a comment on JENKINS-25216 Build Triggers: Option "Build whenever a SNAPSHOT dependency is built" does not work properly It seems that the behaviour is not a bug. Downstream projects are only scheduled if the current project is built successfully. Sounds more like a improvement than a bug to me. 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] [buildresult-trigger-plugin] (JENKINS-25216) Build Triggers: Option "Build whenever a SNAPSHOT dependency is built" does not work properly
Alexander Wolff commented on JENKINS-25216 Build Triggers: Option "Build whenever a SNAPSHOT dependency is built" does not work properly It seems that the behaviour is not a bug. Downstream projects are only scheduled if the current project is built successfully. 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] [delivery-pipeline-plugin] (JENKINS-25607) Unable to trigger manual jobs when build-pipeline-plugin 1.4.4 is installed
Michael Pigg created JENKINS-25607 Unable to trigger manual jobs when build-pipeline-plugin 1.4.4 is installed Issue Type: Bug Assignee: Patrik Boström Components: delivery-pipeline-plugin Created: 13/Nov/14 8:46 PM Description: Due to a non-backwards compatible change to the constructor of BuildPipelineView, delivery-pipeline-plugin can not trigger manual jobs when build-pipeline 1.4.4 is installed. See https://github.com/jenkinsci/build-pipeline-plugin/commit/eeba623fd8b6571372837553a0ea4b227bf4fdf4 I want to use delivery-pipeline, but also want the fixes that build-pipeline has in 1.4.4 to support jobs in folders. Backing down to 1.4.3 of build-pipeline avoids the constructor issue at the expense of folder support in build-pipeline. Project: Jenkins Labels: plugin Priority: Minor Reporter: Michael Pigg 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] [subversion-plugin] (JENKINS-18935) Make Subversion plugin support Subversion 1.8
SCM/JIRA link daemon commented on JENKINS-18935 Make Subversion plugin support Subversion 1.8 Code changed in jenkins User: christ66 Path: pom.xml src/main/java/hudson/scm/SvnClientManager.java src/main/resources/hudson/scm/SubversionSCM/global.jelly http://jenkins-ci.org/commit/subversion-plugin/fc8093b49321830a1a55e19910964998998bea8a Log: JENKINS-18935 Upgrade svnkit library to 1.8.7 and add 1.8 in the global workspace options. 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] [subversion-plugin] (JENKINS-18935) Make Subversion plugin support Subversion 1.8
SCM/JIRA link daemon commented on JENKINS-18935 Make Subversion plugin support Subversion 1.8 Code changed in jenkins User: Steven Christou Path: pom.xml src/main/java/hudson/scm/SubversionWorkspaceSelector.java src/main/java/hudson/scm/SvnClientManager.java src/main/java/hudson/scm/subversion/CheckoutUpdater.java src/main/resources/hudson/scm/SubversionSCM/global.jelly src/test/java/hudson/scm/SVNWorkingCopyTest.java http://jenkins-ci.org/commit/subversion-plugin/4a88de9fc6b3eed1b271b65f08541d8bf3a6d8fd Log: Merge pull request #103 from christ66/JENKINS-18935 JENKINS-18935 Add support for subversion 1.8 format Compare: https://github.com/jenkinsci/subversion-plugin/compare/38af37043e4a...4a88de9fc6b3 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] [analysis-core-plugin] (JENKINS-25560) Multi-line messages shall be displayed with line breaks
Ulli Hafner commented on JENKINS-25560 Multi-line messages shall be displayed with line breaks The message is directly copied into the HTML document. All browsers ignore line breaks in rendering. 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] [tfs-plugin] (JENKINS-21460) TFS plugin throws NumberFormatException
Nagendra Singh commented on JENKINS-21460 TFS plugin throws NumberFormatException I am getting the same error. Anyone got any idea? 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] [subversion-plugin] (JENKINS-18935) Make Subversion plugin support Subversion 1.8
Steven Christou commented on JENKINS-18935 Make Subversion plugin support Subversion 1.8 Let's create an improvement issue to add a checkbox for users to force a workspace version (can assign to me). Going back to the 1.8 migration, since it looks like multiple people confirm that this works I think we should be safe to merge. 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] [checkstyle-plugin] (JENKINS-25511) Checkstyle double-escapes content
Ulli Hafner commented on JENKINS-25511 Checkstyle double-escapes content Yes, this is implemented in analysis-core due to JENKINS-17309. I think this change was to aggressive and should be applied only to parsers of non-XML files. I think each tool that produces XML files should already escape correctly. 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] [checkstyle-plugin] (JENKINS-25511) Checkstyle double-escapes content
Alexander Obuhovich commented on JENKINS-25511 Checkstyle double-escapes content Thanks for looking into it. Same thing might be happening with /pmdResult/api/json page as well. I guess there is some central place, that once fixed will fix all such result pages. 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] [cli] (JENKINS-25606) PrivateKeyProviderTest (in Jenkins.CLI) fails when doing Maven build of Jenkins source
Joshua Strouse created JENKINS-25606 PrivateKeyProviderTest (in Jenkins.CLI) fails when doing Maven build of Jenkins source Issue Type: Bug Assignee: Unassigned Attachments: mvnout.txt Components: cli Created: 13/Nov/14 8:00 PM Description: When building Jenkins from source (using the command 'mvn -Plight-test install'), the following error is given during test execution: PrivateKeyProviderTest.initializationError » IllegalState Failed to transform I followed the build instructions at: https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins The full output of Maven is attached. Environment: Jenkins source code tag 'jenkins-1.589'. Java 1.8.0-25. Maven 3.2.3. Windows 7 x64 and Mac OS X 10.9 Project: Jenkins Priority: Blocker Reporter: Joshua Strouse 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] [jobconfighistory-plugin] (JENKINS-25605) More easily map build instances to the configuration it was run it
Ken Beal created JENKINS-25605 More easily map build instances to the configuration it was run it Issue Type: New Feature Assignee: Mirko Friedenhagen Components: jobconfighistory-plugin Created: 13/Nov/14 7:32 PM Description: It would be useful to be able to see, at a glance, the configuration change lines with the build(s) that were done between them, interspersed. This way it would be easier to determine which build instances were run with which configuration change. One way could be to "draw lines" from the builds in the left column, to the configuration that build was run in, but I'm not sure whether line-drawing across columns can be done. The benefit to this is it wouldn't take any more screen real-estate. Another way is to put the builds that were run in between; in the below, each of the "#nn" would be a link to that build instance, like the builds in the left column; the "Build" line indicates that that (or those) build(s) was (were) done using the configuration line directly below it: Build #12, #13, #14 2014-11-11_17-31-35 Changed kbeal View as XML (RAW) 2014-11-11_17-30-29 Changed kbeal View as XML (RAW) Restore Build #11 2014-11-11_17-28-46 Changed kbeal View as XML (RAW) Restore 2014-11-10_18-46-38 Changed kbeal View as XML (RAW) Restore 2014-11-10_18-38-30 Changed kbeal View as XML (RAW) Restore Build #10, #9, #8 2014-11-10_18-37-43 Changed kbeal View as XML (RAW) Restore 2014-11-10_18-35-54 Changed kbeal View as XML (RAW) Restore Build #7 2014-11-10_18-32-34 Changed kbeal View as XML (RAW) Restore Build #6 2014-11-10_18-32-33 Changed kbeal View as XML (RAW) Restore Build #5 2014-11-10_18-32-32 Changed kbeal View as XML (RAW) Restore Build #4 2014-11-10_18-32-28 Created SYSTEM View as XML (RAW) Restore Build #3, #2, #1 2014-11-10_18-32-27 Changed kbeal View as XML (RAW) Restore Project: Jenkins Priority: Minor Reporter: Ken Beal 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] [chef-identity-plugin] (JENKINS-25555) Delete .chef folder after job has ran
Tyler Fitch started work on JENKINS-2 Delete .chef folder after job has ran Change By: Tyler Fitch (13/Nov/14 7:27 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] [maven-plugin] (JENKINS-22486) API change in maven 3.2.1 causes builds with the parallel (-T option) to fail with an exception.
Steve Storey commented on JENKINS-22486 API change in maven 3.2.1 causes builds with the parallel (-T option) to fail with an exception. I've made some changes to add Maven 3.2 support specifically for the purposes of supporting multi-threaded builds there. Pull requests https://github.com/jenkinsci/maven-interceptors/pull/5 and https://github.com/jenkinsci/maven-plugin/pull/32 cover the functionality. For those happy to build + install their own plugin (these instructions skip tests for expediency - you should be able to run the tests too!): git clone https://github.com/Wahanda/maven-interceptors.git cd maven-interceptors mvn install -DskipTests cd .. git clone https://github.com/Wahanda/maven-plugin.git cd maven-plugin mvn package -DskipTests You should then have an HPI file than can be uploaded to you Jenkins install in maven-plugin/target/maven-plugin.hpi. Following installation you should be able to use the -T4 and -T1C syntax. 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] [git-plugin] (JENKINS-25580) Git plugin polls incorrect branch
Nathan Gray edited a comment on JENKINS-25580 Git plugin polls incorrect branch As somebody who has done way too much git scripting I can appreciate how tricky this stuff is, but the plugin is just plain doing the wrong thing. I've specified an unambiguous branch and it's randomly dropped part of the name. I've asked it to poll "origin/release/flow" and it's polling "flow". The "origin" part is correctly removed but what happened to "release"? Note that this is a regression from the last version of the plugin I used, where "origin/release/flow" did the right thing. I'm not asking for new behavior, I'm asking for previously working branch names to work again. Looking at the code, normalizeBranchSpec is broken (and there's even a comment in the code saying so). Taking the last component of the branch name is going to be wrong a lot. I wonder if you're aware that git already provides branch normalization with "git rev-parse --symbolic-full-name": [nathangray@n8bookpro]% git rev-parse --symbolic-full-name release/flow refs/heads/release/flow [nathangray@n8bookpro]% git rev-parse --symbolic-full-name heads/release/flow refs/heads/release/flow [nathangray@n8bookpro]% git rev-parse --symbolic-full-name origin/release/flow refs/remotes/origin/release/flow [nathangray@n8bookpro]% git rev-parse --symbolic-full-name remotes/origin/release/flow refs/remotes/origin/release/flow Couldn't you use that instead of trying to do it yourself? 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] [git-plugin] (JENKINS-25580) Git plugin polls incorrect branch
Nathan Gray commented on JENKINS-25580 Git plugin polls incorrect branch As somebody who has done way too much git scripting I can appreciate how tricky this stuff is, but the plugin is just plain doing the wrong thing. I've specified an unambiguous branch and it's randomly dropped part of the name. I've asked it to poll "origin/release/flow" and it's polling "flow". The "origin" part is correctly removed but what happened to "release"? Note that this is a regression from the last version of the plugin I used, where "origin/release/flow" did the right thing. I'm not asking for behavior to change, I'm asking for previously working branch names to work again. Looking at the code, normalizeBranchSpec is broken (and there's even a comment in the code saying so). Taking the last component of the branch name is going to be wrong a lot. I wonder if you're aware that git already provides branch normalization with "git rev-parse --symbolic-full-name": [nathangray@n8bookpro]% git rev-parse --symbolic-full-name release/flow refs/heads/release/flow [nathangray@n8bookpro]% git rev-parse --symbolic-full-name heads/release/flow refs/heads/release/flow [nathangray@n8bookpro]% git rev-parse --symbolic-full-name origin/release/flow refs/remotes/origin/release/flow [nathangray@n8bookpro]% git rev-parse --symbolic-full-name remotes/origin/release/flow refs/remotes/origin/release/flow Couldn't you use that instead of trying to do it yourself? 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-25594) Tried to install latest war file and gt error and reverted to old war 1.572 and still get errors..
Justin Yesudasan closed JENKINS-25594 as Not A Defect Tried to install latest war file and gt error and reverted to old war 1.572 and still get errors.. Change By: Justin Yesudasan (13/Nov/14 7:15 PM) 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] [matrix-project-plugin] (JENKINS-25604) MatrixConfiguration.useShortWorkspaceName does not alter the workspace path
Oliver Gondža commented on JENKINS-25604 MatrixConfiguration.useShortWorkspaceName does not alter the workspace path Reproducing in https://github.com/jenkinsci/matrix-project-plugin/pull/12 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] [checkstyle-plugin] (JENKINS-25511) Checkstyle double-escapes content
Ulli Hafner commented on JENKINS-25511 Checkstyle double-escapes content Seems that Java Checkstyle also escapes entities so it should be easy to get this right for both worlds. 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-19728) Much needed dependency management between jobs
Donald Morton commented on JENKINS-19728 Much needed dependency management between jobs Kevin, have you looked at Gradle for your C++ dependency management? 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-25603) PR's are stuck using old configuration values
Travis Johnson commented on JENKINS-25603 PR's are stuck using old configuration values I have a PR that I believe fixes this: https://github.com/jenkinsci/ghprb-plugin/pull/60/files (along with others). It warrants some of it's own tests, but that may take me a while as I'm not familiar with testing jenkins plugins. 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] [active-directory-plugin] (JENKINS-3761) When login j_acegi_security_check return a 404 error
Oliver Gondža updated JENKINS-3761 When login j_acegi_security_check return a 404 error Change By: Oliver Gondža (13/Nov/14 6:44 PM) Component/s: matrix-project-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] [active-directory-plugin] (JENKINS-3761) When login j_acegi_security_check return a 404 error
Oliver Gondža updated JENKINS-3761 When login j_acegi_security_check return a 404 error Change By: Oliver Gondža (13/Nov/14 6:44 PM) Component/s: matrix-auth-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] [matrix-project-plugin] (JENKINS-25604) MatrixConfiguration.useShortWorkspaceName does not alter the workspace path
Oliver Gondža created JENKINS-25604 MatrixConfiguration.useShortWorkspaceName does not alter the workspace path Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: matrix-project-plugin Created: 13/Nov/14 6:41 PM Description: Passing -Dhudson.matrix.MatrixConfiguration.useShortWorkspaceName=test does not seem to have any effect at all. Project: Jenkins Priority: Minor Reporter: Oliver Gondža 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-25603) PR's are stuck using old configuration values
Travis Johnson created JENKINS-25603 PR's are stuck using old configuration values Issue Type: Bug Assignee: Honza Brázdil Components: ghprb-plugin Created: 13/Nov/14 6:39 PM Description: it appears once a PR is created (and detected by ghprb) the current configuration values are copied into the PR object. As a result, changes in configuration (whitelist, admins, trigger commands, etc) are not reflected in existing PR's. Project: Jenkins Priority: Minor Reporter: Travis Johnson 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-25603) PR's are stuck using old configuration values
Travis Johnson updated JENKINS-25603 PR's are stuck using old configuration values Change By: Travis Johnson (13/Nov/14 6:40 PM) Environment: Jenkins: 1.580.1 ghprb-plugin: 1.16-5 OS: Ubuntu 12.04.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] [cloudbees-folder-plugin] (JENKINS-25595) After copying a Folder, all jobs within it are disabled
Jesse Glick commented on JENKINS-25595 After copying a Folder, all jobs within it are disabled Specifically to prevent scheduled triggers from running until after you have verified that the new version of the job is actually right. 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] [p4-plugin] (JENKINS-25602) Testing connection to an SSL server fails with 'Connection Error.'
Rob Petti assigned JENKINS-25602 to Unassigned Testing connection to an SSL server fails with 'Connection Error.' Change By: Rob Petti (13/Nov/14 6:21 PM) Assignee: Rob Petti 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] [p4-plugin] (JENKINS-25602) Testing connection to an SSL server fails with 'Connection Error.'
Rob Petti updated JENKINS-25602 Testing connection to an SSL server fails with 'Connection Error.' Filed under the wrong component. Change By: Rob Petti (13/Nov/14 6:21 PM) Component/s: p4-plugin Component/s: perforce-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] [perforce-plugin] (JENKINS-25602) Testing connection to an SSL server fails with 'Connection Error.'
Matthew Douglass created JENKINS-25602 Testing connection to an SSL server fails with 'Connection Error.' Issue Type: Bug Assignee: Rob Petti Components: perforce-plugin Created: 13/Nov/14 6:15 PM Description: The following messages appear in the Jenkins System Log: Nov 13, 2014 3:33:30 AM SEVERE org.jenkinsci.plugins.p4.client.ConnectionHelper connect P4: Unable to connect: com.perforce.p4java.exception.ConnectionException: The authenticity of '*** removed ***' can't be established, this may be your first attempt to connect to this Perforce server. The fingerprint for the public key sent to your client is *** removed *** To allow connection use the 'addTrust' method with the 'autoAccept' option. Environment: Jenkins 1.585 p4 1.0.20 Project: Jenkins Priority: Major Reporter: Matthew Douglass 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] [perforce-plugin] (JENKINS-25602) Testing connection to an SSL server fails with 'Connection Error.'
Matthew Douglass commented on JENKINS-25602 Testing connection to an SSL server fails with 'Connection Error.' I have verified that the correct Trust parameter is set in the credentials for this connection. 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] [cloudbees-folder-plugin] (JENKINS-25595) After copying a Folder, all jobs within it are disabled
Aritz Bastida commented on JENKINS-25595 After copying a Folder, all jobs within it are disabled Thanks! It was confusing to me, but I understand now that it has been implemented this way to prevent accidental runs... 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] [cloudbees-folder-plugin] (JENKINS-25595) After copying a Folder, all jobs within it are disabled
Daniel Beck commented on JENKINS-25595 After copying a Folder, all jobs within it are disabled Any job you copy is disabled (or rather, not buildable) by default. You usually don't recognize it because the form opens and you generally change things, and upon Saving the job becomes buildable. 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] [lockable-resources-plugin] (JENKINS-25569) Lockable resource job stuck at "default is still in the queue: Waiting for resources [my_resource]"
Jonathan Strickland commented on JENKINS-25569 Lockable resource job stuck at "default is still in the queue: Waiting for resources [my_resource]" Found that the QueueTaskDispatcher is being called multiple times (LockableResourcesQueueTaskDispatcher) but is appears that there is no distinction in when its being called at different points in the queue. Appears since its being called multiple times and attempting to queue up resources each time that basically get stuck waiting for resources. See below: Nov 13, 2014 11:56:51 AM INFO hudson.WebAppMain$3 run Jenkins is fully up and running Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher canRun Full stack trace is in canRun: [java.lang.Thread.getStackTrace(Thread.java:1568), org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher.canRun(LockableResourcesQueueTaskDispatcher.java:41), hudson.model.Queue.isBuildBlocked(Queue.java:949), hudson.model.Queue.maintain(Queue.java:1018), hudson.model.Queue$1.call(Queue.java:316), hudson.model.Queue$1.call(Queue.java:313), jenkins.util.AtmostOneTaskExecutor$1.call(AtmostOneTaskExecutor.java:94), jenkins.util.AtmostOneTaskExecutor$1.call(AtmostOneTaskExecutor.java:84), java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334), java.util.concurrent.FutureTask.run(FutureTask.java:166), hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:104), java.lang.Thread.run(Thread.java:724)] Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher canRun Reserve_Upgrade9k trying to reserve 1 of [ASR9K] Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher canRun PROJECT FULLNAME:Reserve_Upgrade9k NAME:Reserve_Upgrade9k Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager queue Selecting resources for queueItemId:1 queueItemProject:Reserve_Upgrade9k number:1 Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager queue Checking resource ASR9K with project name null with queueItemsId 0 Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager queue Validating rs ASR9K isReserved:false isLocked:false isQueue:false Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager queue Selected size is 1 Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher canRun Reserve_Upgrade9k reserved resources [ASR9K] Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager lock Entering lock resources Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager lock Full stack trace is: [java.lang.Thread.getStackTrace(Thread.java:1568), org.jenkins.plugins.lockableresources.LockableResourcesManager.lock(LockableResourcesManager.java:157), org.jenkins.plugins.lockableresources.queue.LockRunListener.onStarted(LockRunListener.java:48), org.jenkins.plugins.lockableresources.queue.LockRunListener.onStarted(LockRunListener.java:28), hudson.model.listeners.RunListener.fireStarted(RunListener.java:213), hudson.model.Run.execute(Run.java:1755), hudson.matrix.MatrixBuild.run(MatrixBuild.java:306), hudson.model.ResourceController.execute(ResourceController.java:89), hudson.model.Executor.run(Executor.java:240), hudson.model.OneOffExecutor.run(OneOffExecutor.java:43)] Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.LockableResourcesManager lock Exiting lock resources with true Nov 13, 2014 12:11:41 PM INFO org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher canRun Full stack trace is in canRun: [java.lang.Thread.getStackTrace(Thread.java:1568), org.jenkins.plugins.lockableresources.queue.LockableResourcesQueueTaskDispatcher.canRun(LockableResourcesQueueTaskDispatcher.java:41), hudson.model.Queue.isBuildBlocked(Queue.java:949), hudson.model.Queue.maintain(Queue.java:1018), hudson.model.Queue$1.call(Queue.java:316), hudson.model.Queue$1.call(Queue.java:313), jenkins.util.AtmostOneTaskExecutor$1.call(AtmostOneTaskExecutor.java:94), jenkins.util.AtmostOneTaskExecutor$1.call(AtmostOneTaskExecutor.java:84), java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334), java.util.concurrent.Fu
[JIRA] [core] (JENKINS-19728) Much needed dependency management between jobs
Kevin Phillips commented on JENKINS-19728 Much needed dependency management between jobs the things that just could not be done as separate jobs with triggers without losing your mind. Very well put! Unfortunately I think I lost my mind on this stuff at least a year ago or more. 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-19728) Much needed dependency management between jobs
Kevin Phillips commented on JENKINS-19728 Much needed dependency management between jobs Thanks for clarifying. Ironically, I have been reading a lot about Maven lately since our company does have a small Java development team that uses it, and I'm trying to evaluate whether any of those tools may be usable by our native development teams. So far it's not looking good. I do have to say that on some level I am, as a mainly native C++ developer, jealous at the tools available to Java developers, most notably Maven. They do provide a lot of features that are sadly missing or, at best, very difficult to find in native toolsets. 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] [cloudbees-folder-plugin] (JENKINS-25595) After copying a Folder, all jobs within it are disabled
Jesse Glick resolved JENKINS-25595 as Duplicate After copying a Folder, all jobs within it are disabled Change By: Jesse Glick (13/Nov/14 5:11 PM) Status: Open Resolved Resolution: Duplicate 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-19728) Much needed dependency management between jobs
Jesse Glick commented on JENKINS-19728 Much needed dependency management between jobs From what I understand this plugin isn't yet available on the Jenkins plugin 'store', correct? There are beta releases available on the experimental update center. Please see its project page for details, or use jenkinsci-dev for questions. Do you have any thoughts as to when it will be "production ready"? 1.0 is expected very soon, for what that’s worth. I cannot promise this would solve all of your requirements (even if and when a changelog operator is implemented), but it is the only plausible candidate, which is why Kohsuke & I have been spending so much time on it. Your use cases are exactly in line with what we envisioned as the interesting problems to be solved—the things that just could not be done as separate jobs with triggers without losing your mind. 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] [xshell-plugin] (JENKINS-25600) XShell does not kill running process if job is getting aborted
Henrik Skupin commented on JENKINS-25600 XShell does not kill running process if job is getting aborted Oh, and this is indeed a regression between version 0.8 and 0.9. 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-25582) Installing Jenkins service the slave cannot re-connect after first system restart
Oleg Nenashev commented on JENKINS-25582 Installing Jenkins service the slave cannot re-connect after first system restart It happens due to TCP Timeout and PingThread on the master. Jenkins master consider a slave as connected if... There's no failed requests from master to slave PingThread has not failed with 4-minutes timeout (it's hardcoded now) In order to fix the issue, reconfigure the reconnect interval in Slave Service configuration. It will decrease the frequency of connection attempts. 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] [xshell-plugin] (JENKINS-25600) XShell does not kill running process if job is getting aborted
Henrik Skupin commented on JENKINS-25600 XShell does not kill running process if job is getting aborted Could this have been caused by https://github.com/jenkinsci/xshell-plugin/pull/8? 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-19728) Much needed dependency management between jobs
Kevin Phillips edited a comment on JENKINS-19728 Much needed dependency management between jobs Not when using Workflow. One job with one Groovy script which can work however you like, with no additional plugins. This does sound promising. From what I understand this plugin isn't yet available on the Jenkins plugin 'store', correct? Do you have any thoughts as to when it will be "production ready"? I definitely would like to give it a try when it is deemed "stable". The biggest issue I'd have with it would be having to take the time to learn Groovy and the plugin and then to write a script to handle some of these seemingly trivial use cases, but it's one of those things where if there are no other options at our disposal then we may have no other choice. The other thing we'd need to do is test the plugin in-house to make sure that adopting a new plugin such as this wouldn't have an adverse effect on the dozens of other plugins we're currently using. As I mentioned before, we have experienced numerous inter-relationship problems between plugins in the past. I do not think anything like this will or should become part of “basic Jenkins infrastructure”. Obviously I'm not familiar with the internals of the tool itself, nor am I a maintainer or even an active contributor to the project (yet), so obviously I can't speak to whether such features will be incorporated into the core. However, given the importance and benefits of supporting correct dependency management I think it is pretty clear that these features should be incorporated into the core. The architecture would need to model the concepts of dependencies from the bottom up in order for it to be robustly supported - across plugins, across configurations, etc. The dependency & triggering logic built into Jenkins core is already far too complex. That is why we created Workflow—the existing system did not scale up to more sophisticated scenarios. I suspected this was the case. It sounds like some of that code needs to be refactored to compensate for the added complexity. I probably should say that I do understand that what I am proposing here would likely be invasive and would require a lot of work, but as a result I believe that doing so would be a game changer for Jenkins which would further encourage it's adoption in the corporate world where such things are of critical importance. For example, if the core architecture supported dependency management and these features were exposed on the Jenkins UI via easy to understand interfaces then even non-developers can get involved with the automated process management. Exposing this feature via a scripting environment, while very flexible and powerful I'm sure, does preclude / discourage non-developers from using it. 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-25582) Installing Jenkins service the slave cannot re-connect after first system restart
Oleg Nenashev updated JENKINS-25582 Installing Jenkins service the slave cannot re-connect after first system restart Change By: Oleg Nenashev (13/Nov/14 5:05 PM) Labels: service winsw 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-19728) Much needed dependency management between jobs
Jesse Glick commented on JENKINS-19728 Much needed dependency management between jobs I don't think you can ever get away from having to manually model your release process in the tool of your choice, Jenkins or otherwise. At best you can extract parts of that model from tools and build scripts, but you'll never quite get everything you need from there Agreed, and I was not suggesting otherwise. Just saying that there are cases where you have a large number of modules with a completely consistent, homogeneous model—each has a static dependency list on other modules, and each accepts a predefined “build & test” command which is considered a prerequisite for building downstream modules. For this scenario, it is helpful to have some kind of tool which either automatically scans for dependencies, or accepts a DSL with a manually managed yet concise description of dependencies, and implements the minimal build sequence (with topological sorting, or automatic parallelization, etc.). For example, if you are using Maven with a reactor build (one big repository with lots of submodules with SNAPSHOT dependencies), and can determine which modules have changes according to the file list in the changelog of the current build, you can pass that module list as --also-make-dependents B,K,P,Q --threads 2.0C and get an easy parallelized, minimal build. There are of course other scenarios where every dependency is idiosyncratic enough that you have to model the whole behavior from scratch. And there is often some kind of setup stage and/or final deployment stage that falls outside a fixed dependency model. Neither poses any problem for 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] [core] (JENKINS-25584) Improve error outputs if IOException happens on the disk overflow
Oleg Nenashev updated JENKINS-25584 Improve error outputs if IOException happens on the disk overflow Not a bug in any case. I'm not sure if the proposed improvement can be implemented in general case. Any disk operation in Jenkins core or plugin may fail, hence it's hard to handle a specific disk overflow case everywhere. The current behavior in enough IMO Change By: Oleg Nenashev (13/Nov/14 4:59 PM) Summary: change descriptor leads to RuntimeException Improve error outputs if IOException happens on the disk overflow Issue Type: Bug Improvement 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-19728) Much needed dependency management between jobs
Kevin Phillips edited a comment on JENKINS-19728 Much needed dependency management between jobs Not when using Workflow. One job with one Groovy script which can work however you like, with no additional plugins. This does sound promising. From what I understand this plugin isn't yet available on the Jenkins plugin 'store', correct? Do you have any thoughts as to when it will be "production ready"? I definitely would like to give it a try when it is deemed "stable". The biggest issue I'd have with it would be having to take the time to learn Groovy and the plugin and then to write a script to handle some of these seemingly trivial use cases, but it's one of those things where if there are no other options at our disposal then we may have no other choice. The other thing we'd need to do is test the plugin in-house to make sure that adopting a new plugin such as this wouldn't have an adverse effect on the dozens of other plugins we're currently using. As I mentioned before, we have experienced numerous inter-relationship problems between plugins in the past. I do not think anything like this will or should become part of “basic Jenkins infrastructure”. Obviously I'm not familiar with the internals of the tool itself, nor am I a maintainer or even an active contributor to the project (yet), so obviously I can't speak to whether such features will be incorporated into the core. However, given the importance and benefits of supporting correct dependency management I think it is pretty clear that these features should be incorporated into the core. The architecture would need to model the concepts of dependencies from the bottom up in order for it to be robustly supported - across plugins, across configurations, etc. The dependency & triggering logic built into Jenkins core is already far too complex. That is why we created Workflow—the existing system did not scale up to more sophisticated scenarios. I suspected this was the case. It sounds like some of that code needs to be refactored to compensate for the added complexity. I probably should say that I do understand that what I am proposing here would likely be invasive and would require a lot of work, but as a result I believe that doing so would be a game changer for Jenkins which would further encourage it's adoption in the corporate world where such things are of critical importance. 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-19728) Much needed dependency management between jobs
Kevin Phillips edited a comment on JENKINS-19728 Much needed dependency management between jobs Not when using Workflow. One job with one Groovy script which can work however you like, with no additional plugins. This does sound promising. From what I understand this plugin isn't yet available on the Jenkins plugin 'store', correct? Do you have any thoughts as to when it will be "production ready"? I definitely would like to give it a try when it is deemed "stable". The biggest issue I'd have with it would be having to take the time to learn Groovy and the plugin and then to write a script to handle some of these seemingly trivial use cases, but it's one of those things where if there are no other options at our disposal then we may have no other choice. The other thing we'd need to do is test in-house as well is to make sure that adopting a new plugin such as this wouldn't have an adverse effect on the dozens of other plugins we're currently using. As I mentioned before, we have experienced numerous inter-relationship problems between plugins in the past. I do not think anything like this will or should become part of “basic Jenkins infrastructure”. Obviously I'm not familiar with the internals of the tool itself, nor am I a maintainer or even an active contributor to the project (yet), so obviously I can't speak to whether such features will be incorporated into the core. However, given the importance and benefits of supporting correct dependency management I think it is pretty clear that these features should be incorporated into the core. The architecture would need to model the concepts of dependencies from the bottom up in order for it to be robustly supported - across plugins, across configurations, etc. The dependency & triggering logic built into Jenkins core is already far too complex. That is why we created Workflow—the existing system did not scale up to more sophisticated scenarios. I suspected this was the case. It sounds like some of that code needs to be refactored to compensate for the added complexity. I probably should say that I do understand that what I am proposing here would likely be invasive and would require a lot of work, but as a result I believe that doing so would be a game changer for Jenkins which would further encourage it's adoption in the corporate world where such things are of critical importance. 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-19728) Much needed dependency management between jobs
Kevin Phillips commented on JENKINS-19728 Much needed dependency management between jobs Not when using Workflow. One job with one Groovy script which can work however you like, with no additional plugins. This does sound promising. From what I understand this plugin isn't yet available on the Jenkins plugin 'store', correct? Do you have any thoughts as to when it will be "production ready"? I definitely would like to give it a try when it is deemed "stable". The biggest issue I'd have with it would be having to take the time to learn Groovy and the plugin and then to write a script to handle some of these seemingly trivial use cases, but it's one of those things where if there are no other options at our disposal then we may have no other choice. The other thing we'd need to test in-house as well is to make sure that adopting a new plugin such as this wouldn't have an adverse effect on the dozens of other plugins we're currently using. As I mentioned before, we have experienced numerous inter-relationship problems between plugins in the past. I do not think anything like this will or should become part of “basic Jenkins infrastructure”. Obviously I'm not familiar with the internals of the tool itself, nor am I a maintainer or even an active contributor to the project (yet), so obviously I can't speak to whether such features will be incorporated into the core. However, given the importance and benefits of supporting correct dependency management I think it is pretty clear that these features should be incorporated into the core. The architecture would need to model the concepts of dependencies from the bottom up in order for it to be robustly supported - across plugins, across configurations, etc. The dependency & triggering logic built into Jenkins core is already far too complex. That is why we created Workflow—the existing system did not scale up to more sophisticated scenarios. I suspected this was the case. It sounds like some of that code needs to be refactored to compensate for the added complexity. I probably should say that I do understand that what I am proposing here would likely be invasive and would require a lot of work, but as a result I believe that doing so would be a game changer for Jenkins which would further encourage it's adoption in the corporate world where such things are of critical importance. 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] [cloudbees-folder-plugin] (JENKINS-25597) Move icon not shown correctly in some job types
Jesse Glick started work on JENKINS-25597 Move icon not shown correctly in some job types Change By: Jesse Glick (13/Nov/14 4:49 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] [core] (JENKINS-25601) JDK9 with jigsaw file layer is not detected as valid JDK
Eric Barboni created JENKINS-25601 JDK9 with jigsaw file layer is not detected as valid JDK Issue Type: Bug Assignee: Unassigned Components: core Created: 13/Nov/14 4:45 PM Description: Hi, The new jigsaw jdk is not detected as valid jdk because tools.jar and dt.jar are removed from the lib path but are needed by jenkins for detection. file: hudson/model/JDK.java method: checkHomeDirectory Not sure how to make a nice validation for current and jigsaw jdk. As a workaround having void tools.jar and dt.jar allow jdk detection by jenkins. Environment: - fedora 20. jdk8_25 - build jigsaw jdk: build 1.9.0-ea-jigsaw-nightly-h1689-20141110-b38, mixed mode Project: Jenkins Priority: Minor Reporter: Eric Barboni 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] [xshell-plugin] (JENKINS-25600) XShell does not kill running process if job is getting aborted
Henrik Skupin created JENKINS-25600 XShell does not kill running process if job is getting aborted Issue Type: Bug Assignee: Unassigned Components: xshell-plugin Created: 13/Nov/14 4:42 PM Description: As we have seen lately XShell is not able to kill a running process once it is running on the slave, and the user aborts the job on the master machine. Current result is that the job is marked as aborted on the master, but it is still running on the client. This totally breaks our testruns because Jenkins thinks the node is free again, and schedules the next job for this node. But given that by our definition only a single job can run on a node, it will fail. The Jenkins log shows the following when aborting a job: mozilla-aurora_update #2 aborted java.lang.InterruptedException: sleep interrupted at java.lang.Thread.sleep(Native Method) at hudson.plugins.xshell.XShellBuilder.perform(XShellBuilder.java:158) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:585) at hudson.model.Run.execute(Run.java:1684) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Environment: Jenkins 1.580.1 with XShell 0.9 Project: Jenkins Priority: Critical Reporter: Henrik Skupin 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] [selenium-plugin] (JENKINS-25583) Unexpected error in launching a slave. This is probably a bug in Jenkins.
Neal Storey commented on JENKINS-25583 Unexpected error in launching a slave. This is probably a bug in Jenkins. I reverted back to 1.586 which is actually what I was on prior to the upgrade (typo above). Node is back online. 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-19728) Much needed dependency management between jobs
Kevin Phillips commented on JENKINS-19728 Much needed dependency management between jobs I just wanted to make one further clarification in response to Jesse's comment above. Correct me if I'm mistaken, but I think in your comment you may be confusing the concept of "code dependencies" or "build dependencies" with "operational dependencies". What I mean to say is that, while it is true that as developers we probably tend to model Jenkins' job dependencies on our code modules' dependencies, there is not always a 1:1 relationship in that mapping. Often times we'll need to have operations executed as part of the automation process that have nothing to do with compilation but are still required by business processes. For example, if the code for Module A depends on the code of Module B and we use two separate Jenkins jobs to compile each of these then it's pretty clear what the dependencies must be (ie: this is where make and other such tools come into play). However, suppose we have 3 "phases" of a build process: compile, test, package, each of which managed by a separate job. Who is to say how those three jobs should relate / depend on one another? Should packages be dependent on tests? That depends on the context and the policies that govern your release process. This, imo, is where tools like Jenkins really need to shine. Sure the code dependencies need to be taken into account, and granted most of my earlier examples tend to favor such examples, but they are by no means the only source of dependencies your system needs to model. Consequently, I don't think you can ever get away from having to manually model your release process in the tool of your choice, Jenkins or otherwise. At best you can extract parts of that model from tools and build scripts, but you'll never quite get everything you need from there - at least not when you work at scale. 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-10442) RestartNotSupportedException when trying to do safeRestart
Daniel Beck updated JENKINS-10442 RestartNotSupportedException when trying to do safeRestart Change By: Daniel Beck (13/Nov/14 4:21 PM) Component/s: safe-restart Component/s: saferestart-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] [core] (JENKINS-19728) Much needed dependency management between jobs
Jesse Glick commented on JENKINS-19728 Much needed dependency management between jobs even when I want to do this manual configuration myself I currently need to make use of at least a dozen different plugins to accomplish the task Not when using Workflow. One job with one Groovy script which can work however you like, with no additional plugins. In the case of your diamond dependency scenario, I think all that is really missing today is the aforementioned operator to skip a stage when there are no SCM changes in that area. If you do have dozens of dependencies, it would be convenient to have a library to implement this model based on a simple configuration DSL. I do not think anything like this will or should become part of “basic Jenkins infrastructure”. The dependency & triggering logic built into Jenkins core is already far too complex. That is why we created Workflow—the existing system did not scale up to more sophisticated scenarios. 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-24895) An existing connection was forcibly closed by the remote host
Daniel Beck commented on JENKINS-24895 An existing connection was forcibly closed by the remote host Is anyone experiencing this problem without running a tool that forces disconnecting established network connections? Sharon? 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-25594) Tried to install latest war file and gt error and reverted to old war 1.572 and still get errors..
Daniel Beck resolved JENKINS-25594 as Not A Defect Tried to install latest war file and gt error and reverted to old war 1.572 and still get errors.. Not a bug, as downgrading is not generally supported. For assistance in running newer versions, please ask on the jenkinsci-users mailing list, or on #jenkins on Freenode. Change By: Daniel Beck (13/Nov/14 4:17 PM) Status: Open Resolved Resolution: Not A Defect 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] [p4-plugin] (JENKINS-25596) NPE during polling with matrix build
Paul Allen closed JENKINS-25596 as Fixed NPE during polling with matrix build 1.0.21 Change By: Paul Allen (13/Nov/14 4:15 PM) Status: Open Closed 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] [core] (JENKINS-24895) An existing connection was forcibly closed by the remote host
Andy Waterson commented on JENKINS-24895 An existing connection was forcibly closed by the remote host Same problem here. Unfortunately, I have no control over when SEP updates are done. The end result is randomly disconnecting jobs make the build/test process unreliable. 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-19728) Much needed dependency management between jobs
Kevin Phillips commented on JENKINS-19728 Much needed dependency management between jobs To get the ball rolling, here is an example of some use cases that are difficult if not impossible to achieve at the moment which I would hope would be solved by this improvement: "Part 1: Job Dependency" Suppose a project has a low level 'framework' module and a higher level 'application' module which depends on it. It stands to reason that after building the 'framework' module successfully we should run a build of the 'application' module automatically so as to incorporate those framework changes. In this situation the latter, which we'll refer to as "Job A" depends on the latter which we'll refer to as "Job F". In this situation the expected behavior would be as follows: Job F would only run when changes are made to Job F Job A would be run in either of the following scenarios: Job A has changes made to it Job F has changes to it and those changes have been rebuilt successfully If Job A is currently running and Job F is triggered through some other means it will block until Job A completes If Job F is currently running and Job A is triggered through some other means it will block until Job F completes If builds of both Job A and Job F are pending in a build queue Job F will be run before Job A even if they were triggered in the opposite order In this scenario, the first 2 bullet points are more-or-less built into the Jenkins core via 'triggers', with the exception of item 2.2. So far as I can tell there is no way to prevent dependent projects from building when their upstreams are broken - via plugins or otherwise. Items 3 and 4 are supported by the Jenkins core but for some reason they are disabled by default. IMO if Jenkins implemented correct dependency management these options would be enabled by default. Item 5 is achievable with a fair amount of work through the use of plugins and an assortment of 'tweaks' to the Jenkins configuration. "Part 2: Parallel Dependencies Now, lets extend our example to include a server module, which we'll refer to as "Job S". This module will again depend on Job F - the common framework - but will be completely independent to Job A - the application. So in this case this new job would need to exhibit the same behavior as described for "Job A" above, which has the following implications: When changes are made to Job A only Job A will be rebuilt - Job F and Job S will not When changes are made to Job S only Job S will be rebuilt - Job F and Job A will not When changes are made to Job F and those changes are built successfully, both Job A and Job S will be rebuilt to integrate the changes When Job F is building and either Job A or Job S (or both) get triggered through some other means, they will block until Job F has completed successfully Job A and Job S should be able to build in parallel If both Job A and Job S are queued for execution, the order of execution does not matter (ie: FIFO priority would seem appropriate to make the order more explicit) If Job A, Job S and Job F all have builds waiting in the queue, Job F should be scheduled to run before either of Job A or Job S regardless of the chronological order in which the builds were triggered. So again, support for the first 3 items is supported by Jenkins core. Item 4 is partially support, with the exception that there is no mechanism that prevents Job A and Job S from building through independent triggers when Job F has finished building unsuccessfully. Items 5 and 6 are inherently supported by the Jenkins core. Finally, item 7 is supported via plugins with some monkeying with the configurations and triggers a bit. "Part 3: Dreaded Diamond Dependency" Finally, lets extend our example to include a dreaded diamond dependency. Suppose now we add a forth job to our configuration which 'packages' the artifacts of all three jobs (ie: creates an installer for them). Let's call this Job I. In this situation Job I requires all other jobs to be built successfully for it to work correctly. This has the following implications: If Job I gets triggered through some means and any of the other jobs are currently running, it must block until their builds are complete If any of the other jobs are broken Job I should not be allowed to build (no files have been built so there is nothing to package) If Job F receives changes, after those changes have been successfully built Job A and Job S must be triggered a
[JIRA] [p4-plugin] (JENKINS-25596) NPE during polling with matrix build
SCM/JIRA link daemon commented on JENKINS-25596 NPE during polling with matrix build Code changed in jenkins User: Paul Allen Path: src/main/java/org/jenkinsci/plugins/p4/PerforceScm.java http://jenkins-ci.org/commit/p4-plugin/e6f59ff55686a18006d994d609aeba0ecae1371d Log: Fix null formatTags in Workspace Fix null formatTags in Workspace, by loading label from the cloned workspace. JENKINS-25596 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] [youtrack-plugin] (JENKINS-24333) No action for executing command from build step
Wolfgang Ziegler commented on JENKINS-24333 No action for executing command from build step Thanks, I tested the experiemental plugin. Having the YOUTRACK_CHANGES variables is great and it seems to generally work except for the option "find issues ids in text" as it still parses the wrong issue IDs for me. I tried it with the YOUTRACK_CHANGES variable as well as with customly entered text - it always parses the issue ID "XYZ" instead of "#XYZ-123". I tried it with DEV and ORD prefixes, but obviously the project shortnames do not matter - the number is missing while the prefix is parsed. E.g., it tried to post to the youtrack issue "DEV" and "ORD" what obviously fails. When I enter an issue ID in the search query, it's working as it should. I'm curious, is that YOUTRACK_CHANGES variable now available in oder build steps as well or just for those youtrack plugin related settings? 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] [xvnc-plugin] (JENKINS-25424) Exception when editing nodes
Jay Berkenbilt reopened JENKINS-25424 Exception when editing nodes I don't think the fix was complete. After applying the fix and restarting, I am still seeing this behavior on slaves starting after they have run Xvnc. If you aren't seeing it, I will try to create a quick formula for reproducing it. We're running the latest LTS. Change By: Jay Berkenbilt (13/Nov/14 3:40 PM) Resolution: Fixed 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] [p4-plugin] (JENKINS-25341) Improve reconcile by using -m option
Morne Joubert commented on JENKINS-25341 Improve reconcile by using -m option We have a BUILD directory where all object and other generated files are stored. This directory gets removed as a pre-scm step. I want to pick the mode that will put the least amount of strain on the P4 server 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] [p4-plugin] (JENKINS-25341) Improve reconcile by using -m option
Paul Allen commented on JENKINS-25341 Improve reconcile by using -m option 15.1 is not released yet, so '-m' is all I can use for the moment. Depending on your build system (if it depends on date/time of source files) then the balance is between the reconcile time without '-m' vs a clean build. If your build does not use the date/time of the source files then '-m' is ok. 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] [p4-plugin] (JENKINS-25341) Improve reconcile by using -m option
Morne Joubert commented on JENKINS-25341 Improve reconcile by using -m option so from Perforce point of view, which is the better option to use ? 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] [build-pipeline-plugin] (JENKINS-25578) Internet Explorer Compatibility
Aaron Kalsnes updated JENKINS-25578 Internet Explorer Compatibility Change By: Aaron Kalsnes (13/Nov/14 3:03 PM) Issue Type: Improvement Bug 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.
