[JIRA] [artifactory] (JENKINS-21235) Artifactory plugin is configured to run post-build, but actually runs pre-Post-Steps
Rob van Oostrum created JENKINS-21235 Artifactory plugin is configured to run post-build, but actually runs pre-Post-Steps Issue Type: Bug Affects Versions: current Assignee: yossis Components: artifactory, maven, maven2 Created: 06/Jan/14 4:38 PM Description: Even though Artifactory plugin is in post-build, artifact deployment happens before post-steps (and it visually appears to actually be running as part of the main build step). So deployment happens regardless of whether a post-step fails or not, which appears to be broken behavior. the Artifactory plugin should respect the order of go, and not run out of sequence. Environment: Jenkins 1.545, Artifactory plugin 2.2.1, Maven integration plugin 2.1 Project: Jenkins Priority: Critical Reporter: Rob van Oostrum 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/groups/opt_out.
[JIRA] [core] (JENKINS-21034) Jenkins Startup Deadlock - QueueSorter.installDefaultQueueSorter and Queue.init
Rob van Oostrum commented on JENKINS-21034 Jenkins Startup Deadlock - QueueSorter.installDefaultQueueSorter and Queue.init @Magnus: I've had this happen after plugin upgrades as well. Yesterday I restarted after upgrading the JDK on Jenkins' server and it deadlocked. Once it deadlocks, restarting again just results in another deadlock. see previous answer I believe my queue had only 2 items in it when I restarted yesterday. It may have been a couple more than that, but not a huge number by any stretch. 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/groups/opt_out.
[JIRA] [core] (JENKINS-21034) Jenkins Startup Deadlock - QueueSorter.installDefaultQueueSorter and Queue.init
Rob van Oostrum edited a comment on JENKINS-21034 Jenkins Startup Deadlock - QueueSorter.installDefaultQueueSorter and Queue.init Ran into this as well. Seems unrelated to the upgrade. It's simply that the queue that's persisted when the Jenkins service shuts down causes a deadlock when Jenkins re-initializes. The quick fix for me was to rename the file (this is on Ubuntu) from queue.xml into something like queue.keep (or you could just remove it altogether). I've had this happen both at Jenkins upgrades, and simply restarting Jenkins after plugin updates, since 1.542 or so. 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/groups/opt_out.
[JIRA] [core] (JENKINS-21034) Jenkins Startup Deadlock - QueueSorter.installDefaultQueueSorter and Queue.init
Rob van Oostrum edited a comment on JENKINS-21034 Jenkins Startup Deadlock - QueueSorter.installDefaultQueueSorter and Queue.init Ran into this as well. Seems unrelated to the upgrade. It's simply that the queue that's persisted when the Jenkins service shuts down causes a deadlock when Jenkins re-initializes. The quick fix for me was to rename the file (this is on Ubuntu) from queue.xml into something like queue.keep (or you could just remove it altogether). I've had this happen both at Jenkins upgrades, and simply restarting Jenkins after plugin updates, since 1.542 or so. Once in this deadlock, downgrading as far as 1.540 didn't do the trick. Ended up upgrading back to 1.544 and removing queue.xml before restarting. 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/groups/opt_out.
[JIRA] [core] (JENKINS-21034) Jenkins Startup Deadlock - QueueSorter.installDefaultQueueSorter and Queue.init
Rob van Oostrum edited a comment on JENKINS-21034 Jenkins Startup Deadlock - QueueSorter.installDefaultQueueSorter and Queue.init Ran into this as well. Seems unrelated to the upgrade. It's simply that the queue that's persisted when the Jenkins service shuts down causes a deadlock when Jenkins re-initializes. The quick fix for me was to rename the file (this is on Ubuntu) from queue.xml into something like queue.xml.keep (or you could just remove it altogether). I've had this happen both at Jenkins upgrades, and simply restarting Jenkins after plugin updates, since 1.542 or so. Once in this deadlock, downgrading as far as 1.540 didn't do the trick. Ended up upgrading back to 1.544 and removing queue.xml before restarting. 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/groups/opt_out.
[JIRA] [core] (JENKINS-21034) Jenkins Startup Deadlock - QueueSorter.installDefaultQueueSorter and Queue.init
Rob van Oostrum commented on JENKINS-21034 Jenkins Startup Deadlock - QueueSorter.installDefaultQueueSorter and Queue.init Ran into this as well. Seems unrelated to the upgrade. It's simply that the queue that's persisted when the Jenkins service shuts down causes a deadlock when Jenkins re-initializes. The quick fix for me was to rename the file (this is on Ubuntu) from queue.xml into something like queue.keep (or you could just remove it altogether) 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/groups/opt_out.
[JIRA] [artifactory] (JENKINS-18052) Make Artifactory respect Jenkins' artifact retention policy, if set
Rob van Oostrum created JENKINS-18052 Make Artifactory respect Jenkins artifact retention policy, if set Issue Type: Improvement Affects Versions: current Assignee: yossis Components: artifactory Created: 22/May/13 8:35 PM Description: In my Maven projects, if I configure Jenkins to retain e.g. 6 months' of build logs, but only artifacts for the last 10 builds, Artifactory retains 6 months' worth of snapshots, which is not what I would expect to happen. The change is to accept Jenkins' artifact retention policy, if set, for the purpose of setting retention on the Artifactory side. https://github.com/jenkinsci/artifactory-plugin/pull/5 Project: Jenkins Priority: Major Reporter: Rob van Oostrum 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/groups/opt_out.
[JIRA] (JENKINS-12972) Add option to run 'git bisect' to find which commit added new bugs
[ https://issues.jenkins-ci.org/browse/JENKINS-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162424#comment-162424 ] Rob van Oostrum commented on JENKINS-12972: --- Probably makes more sense to work off 'git blame' instead: http://linux.die.net/man/1/git-blame Add option to run 'git bisect' to find which commit added new bugs --- Key: JENKINS-12972 URL: https://issues.jenkins-ci.org/browse/JENKINS-12972 Project: Jenkins Issue Type: New Feature Components: analysis-core, core, findbugs, git Reporter: Eyal Edri Priority: Minor Today, when you run find-bugs plug-in triggered by a git commit, you can't know exactly which commit added those bugs. It becomes especially difficult to know when a high volume of commits is pushed at once. find-bugs plug-in could have a new option to tick in the 'advanced section', which will do a 'git bisect' on the git commits that caused a new bug and display/email to commiter who did it. that would simply and automate the process of finding who wrote the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
