Re: Prune in git-plugin 2.0 (probably question for Kohsuke)
need to test, but anyway this refactoring goal was not to fix JENKINS-18834https://issues.jenkins-ci.org/browse/JENKINS-18834, so maybe need some extra effort 2013/8/7 Sapone mylniko...@gmail.com Oh, now I see what happens... Thanks a lot! But what about fact, that prune should be done before fetching? (see JIRA bug) On Tuesday, August 6, 2013 6:39:20 PM UTC+7, nicolas de loof wrote: Isn't https://github.com/**jenkinsci/git-plugin/blob/** refactoring/src/main/java/**hudson/plugins/git/extensions/** impl/PruneStaleBranch.javahttps://github.com/jenkinsci/git-plugin/blob/refactoring/src/main/java/hudson/plugins/git/extensions/impl/PruneStaleBranch.javawhat your looking for ? 2013/8/6 Sapone mylni...@gmail.com Looks like Prune option is completly removed in refactoring branch. Why? Here the bug in JIRA: https://issues.jenkins-ci.org/**browse/JENKINS-18834https://issues.jenkins-ci.org/browse/JENKINS-18834 -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Prune in git-plugin 2.0 (probably question for Kohsuke)
sure, and as you seem to have a concrete use-case to suffer this issue you're feedback is welcome to confirm bug is still present and propose a fix :) 2013/8/7 Sapone mylniko...@gmail.com Indeed, refactoring not about this bug. But my point is - if refactoring affects Prune, and Prune not working well, so may be it would be good to make it right at once, during refactoring. On Wednesday, August 7, 2013 1:50:09 PM UTC+7, nicolas de loof wrote: need to test, but anyway this refactoring goal was not to fix JENKINS-18834 https://issues.jenkins-ci.org/browse/JENKINS-18834, so maybe need some extra effort 2013/8/7 Sapone mylni...@gmail.com Oh, now I see what happens... Thanks a lot! But what about fact, that prune should be done before fetching? (see JIRA bug) On Tuesday, August 6, 2013 6:39:20 PM UTC+7, nicolas de loof wrote: Isn't https://github.com/**jenki**nsci/git-plugin/blob/**refactori** ng/src/main/java/**hudson/**plugins/git/extensions/**impl/** PruneStaleBranch.javahttps://github.com/jenkinsci/git-plugin/blob/refactoring/src/main/java/hudson/plugins/git/extensions/impl/PruneStaleBranch.javawhat your looking for ? 2013/8/6 Sapone mylni...@gmail.com Looks like Prune option is completly removed in refactoring branch. Why? Here the bug in JIRA: https://issues.jenkins-ci.org/browse/JENKINS-18834https://issues.jenkins-ci.org/browse/JENKINS-18834 -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@**googlegroups.**com. For more options, visit https://groups.google.com/**grou**ps/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Jenkins plugin release RSS-feed dead?
Hi, since some days the Plugin-release RSS-feed seems to be dead (last updated extension is FSTrigger from Aug. 1, while there were definitly updates in the update-center later es well. Best regards, Björn -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Updating the standard information on a Plugin wiki page
The code is already hosted on Github, it doesn't make sense to host it in two places. I know where I'm from! :-) -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Prune in git-plugin 2.0 (probably question for Kohsuke)
Damn, I'm somehow messed up my pull requests a bit... sorry for this. Here the tiny fix: https://github.com/jenkinsci/git-plugin/pull/161 Looks like it works fine. Unit tests not affected. On Wednesday, August 7, 2013 2:08:10 PM UTC+7, nicolas de loof wrote: sure, and as you seem to have a concrete use-case to suffer this issue you're feedback is welcome to confirm bug is still present and propose a fix :) 2013/8/7 Sapone mylni...@gmail.com javascript: Indeed, refactoring not about this bug. But my point is - if refactoring affects Prune, and Prune not working well, so may be it would be good to make it right at once, during refactoring. On Wednesday, August 7, 2013 1:50:09 PM UTC+7, nicolas de loof wrote: need to test, but anyway this refactoring goal was not to fix JENKINS-18834 https://issues.jenkins-ci.org/browse/JENKINS-18834, so maybe need some extra effort 2013/8/7 Sapone mylni...@gmail.com Oh, now I see what happens... Thanks a lot! But what about fact, that prune should be done before fetching? (see JIRA bug) On Tuesday, August 6, 2013 6:39:20 PM UTC+7, nicolas de loof wrote: Isn't https://github.com/**jenki**nsci/git-plugin/blob/**refactori** ng/src/main/java/**hudson/**plugins/git/extensions/**impl/** PruneStaleBranch.javahttps://github.com/jenkinsci/git-plugin/blob/refactoring/src/main/java/hudson/plugins/git/extensions/impl/PruneStaleBranch.javawhat your looking for ? 2013/8/6 Sapone mylni...@gmail.com Looks like Prune option is completly removed in refactoring branch. Why? Here the bug in JIRA: https://issues.jenkins-ci.org/browse/JENKINS-18834https://issues.jenkins-ci.org/browse/JENKINS-18834 -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@**googlegroups.**com. For more options, visit https://groups.google.com/**grou**ps/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Updating the standard information on a Plugin wiki page
Traditionally everyone forks their plugins into Jenkins' org... But I wouldn't expect a Culchie to grök that ;-) On 7 August 2013 09:35, Jim Gallagher jegallag...@gmail.com wrote: The code is already hosted on Github, it doesn't make sense to host it in two places. I know where I'm from! :-) -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Updating the standard information on a Plugin wiki page
On Wednesday, 7 August 2013 09:42:10 UTC+1, Stephen Connolly wrote: Traditionally everyone forks their plugins into Jenkins' org... But I wouldn't expect a Culchie to grök that ;-) Tradition isn't a hard fast reason for doing something - I can name 3 other plugins that don't host there. Fighting talk... -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Updating the standard information on a Plugin wiki page
So less than 1% host outside of the Jenkins CI org... On 7 August 2013 09:45, Jim Gallagher jegallag...@gmail.com wrote: On Wednesday, 7 August 2013 09:42:10 UTC+1, Stephen Connolly wrote: Traditionally everyone forks their plugins into Jenkins' org... But I wouldn't expect a Culchie to grök that ;-) Tradition isn't a hard fast reason for doing something - I can name 3 other plugins that don't host there. Fighting talk... -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Updating the standard information on a Plugin wiki page
Hi,
Currently the confluence macro
https://github.com/jenkinsci/backend-jenkins-plugin-info-plugin/blob/master/src/main/java/org/jenkinsci/confluence/plugins/JenkinsPluginInfoMacro.java
only supports the following repositories:
-https://github.com/jenkinsci/
-https://svn.jenkins-ci.org/trunk/hudson/plugins/.
But the script should be easy to adapt to support different repositories with
an extra parameter.
Regards,
Fred
On Thursday, August 1, 2013 10:00:42 AM UTC+2, Jim Gallagher wrote:
My wiki page contains the standard information generated by adding the
snippet
{jenkins-plugin-info:cucumber-perf}
to the page.
https://wiki.jenkins-ci.org/pages/editpage.action?pageId=68386913
However, the links are to the jenkinsci github repo, which is not where
the code is actually hosted. I'd like to be able to change this, and
thought it might be automatically generated from the pom, but it appears
not. Is there a was to update or change this?
TIA
Jim
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[NOTICE] Credentials, SSH Credentials, SSH Agent and SSH Slaves
As part of my improvements to the Credentials plugin I am pushing a whole new set of releases of these plugins. Credentials 1.6 is backwards compatible with all previous releases. It should be safe to upgrade that one on its own. SSH Credentials 1.0 requires Credentials 1.6 and includes a change to the on-disk data format. The consequence of this is that if you upgrade to SSH Credentials 1.0 you may loose credentials if you subsequently decide you made a mistake and decide to revert back to an earlier version... this is because the SSHUserPassword credentials have been migrated to the new StandardUsernamePasswordCredentials type in Credentials 1.6. This plugin is a new Major Version due to the deprecation of quite a few methods and classes. Note that if you do not upgrade SSH Slaves to a release that uses the new method signatures you may find that the Username/password credentials cannot be located. SSH Agent 1.2 requires SSH Credentials 1.0 and Credentials 1.6 but has no other impact. SSH Slaves 1.0 requires SSH Credentials 1.0 and Credentials 1.6. Given that this plugin is widely used, it advertises a change to the on-disk data format (despite there technically not being any) to prevent people accidentally upgrading without being aware that there is a potential impact (namely the changes in SSH Credentials 1.0) This version gets a new Major Version due to the major version change of SSH Credentials. I have done quite a bit of testing, and I am quite confident that the changes are safe... *but* you need to jump with all of them in one go, in other words IF you upgrade either of SSH Slaves or SSH Credentials to 1.0 you MUST ENSURE the other is upgraded also. Thanks for listening -Stephen -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: Request for plugin repository for XebiaLabs Deployit Plugin
created at https://github.com/jenkinsci/deployit-plugin Great, thanks Nic! ap -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Backporting for 1.509.3 started
On Wed, Aug 7, 2013 at 8:01 AM, oliver gondža ogon...@redhat.com wrote: @jesse: Is JENKINS-14362 really resolved? This discussion seems inconclusive to me. There is no definitive verification in JIRA, though I have heard private reports from people trying backport builds that the problem did not recur. I have not seen any reports of similar symptoms accompanied by comparable thread dumps with java.util.zip replaced by jzlib. I believe the issue was closed prematurely (2013-07-19). It was closed when the (purported) fix was integrated into trunk. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Persistent slave
Hi! I am looking for a way to create a new kind of a slave (or a channel or smth) for defining a set of testing machines (virtual and real) in my jenkins. It must meet the following requirements: 1. It should provide additional states like: rebooting, broken, available (and probably some others). The logic of selecting the current state exists already and is related to tha testing process. 2. The job that is being executed on such kind of the slave should be tolerant to slave reboot (until the specified timeout is exceeded) so the build will proceed after reboot normally. I had a look a the exiting plugins and it looks for me that there is no similar plugin for now. Can you please tell me if is it possible and if it is so suggest what plugin can I take as a base or which extension points should I look at to start development? Thanks, Nickolay -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Persistent slave
As far as I know, this isn't possible. The basic slave architecture requires a constant, unbroken connection to the slave. If the connection is broken, the build is considered a failure. There might be ways to handle this in the slave classes, but if there is, I'm not aware of them. See this Stackoverflow Questionhttp://stackoverflow.com/questions/5543413/reconfigure-and-reboot-a-hudson-jenkins-slave-as-part-of-a-buildthat deals with the same issue. There are workarounds, but none quite as elegant as a rebootable slave. On Wednesday, August 7, 2013 7:18:17 AM UTC-7, Nickolay Rumyantsev wrote: Hi! I am looking for a way to create a new kind of a slave (or a channel or smth) for defining a set of testing machines (virtual and real) in my jenkins. It must meet the following requirements: 1. It should provide additional states like: rebooting, broken, available (and probably some others). The logic of selecting the current state exists already and is related to tha testing process. 2. The job that is being executed on such kind of the slave should be tolerant to slave reboot (until the specified timeout is exceeded) so the build will proceed after reboot normally. I had a look a the exiting plugins and it looks for me that there is no similar plugin for now. Can you please tell me if is it possible and if it is so suggest what plugin can I take as a base or which extension points should I look at to start development? Thanks, Nickolay -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: Persistent slave
Hi Nickolay, For virtual you can somewhat accomplish this with the Cloudbees auto scaling plugin. You create a pool of virtual machines, and then assign one to your build which you can access via SSH. You can do whatever you want to to this VM as this VM is not the slave VM - although there are no additional states available. If you feel like coding then you could probably do something similar with the vSphere cloud plugin, or the labmanager plugin. I have a plan to do something similar for physical machines - have a pool - be able to obtain one (or more), control the OS to revert to a snapshot etc.. but have some other things I need to accomplish first, and the extra snapshots will require UCS hardware and some SAN - yet to be determined. /James From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-dev@googlegroups.com] On Behalf Of Jason Swager Sent: 07 August 2013 15:34 To: jenkinsci-dev@googlegroups.com Subject: Re: Persistent slave As far as I know, this isn't possible. The basic slave architecture requires a constant, unbroken connection to the slave. If the connection is broken, the build is considered a failure. There might be ways to handle this in the slave classes, but if there is, I'm not aware of them. See this Stackoverflow Questionhttp://stackoverflow.com/questions/5543413/reconfigure-and-reboot-a-hudson-jenkins-slave-as-part-of-a-build that deals with the same issue. There are workarounds, but none quite as elegant as a rebootable slave. On Wednesday, August 7, 2013 7:18:17 AM UTC-7, Nickolay Rumyantsev wrote: Hi! I am looking for a way to create a new kind of a slave (or a channel or smth) for defining a set of testing machines (virtual and real) in my jenkins. It must meet the following requirements: 1. It should provide additional states like: rebooting, broken, available (and probably some others). The logic of selecting the current state exists already and is related to tha testing process. 2. The job that is being executed on such kind of the slave should be tolerant to slave reboot (until the specified timeout is exceeded) so the build will proceed after reboot normally. I had a look a the exiting plugins and it looks for me that there is no similar plugin for now. Can you please tell me if is it possible and if it is so suggest what plugin can I take as a base or which extension points should I look at to start development? Thanks, Nickolay -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.commailto:jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Persistent slave
Hello Nikolay, i think that i might have a plugin to do what you want. i tried to add this plugin awhile back but didnt get a positive reply for its addition. the plugin name is vmware-esx-plugin and i built this so that i could revert the vm to a specific state, before or after the build, so that i could do repetitive testing. i would still like to add this plugin to the jenkins repo but i havent really pushed it. my username is xterm-one and its location is xterm-one/vmware-esx-plugin. i also had a bank of hardware machines that i used it on to revert to a specific state using a bootable cd (such as hiren) to revert to a specific state using ghost. xterm-one On Wed, Aug 7, 2013 at 10:17 AM, James Nord (jnord) jn...@cisco.com wrote: Hi Nickolay, ** ** For virtual you can somewhat accomplish this with the Cloudbees auto scaling plugin. ** ** You create a pool of virtual machines, and then assign one to your build which you can access via SSH. You can do whatever you want to to this VM as this VM is not the slave VM – although there are no additional states available. If you feel like coding then you could probably do something similar with the vSphere cloud plugin, or the labmanager plugin. ** ** I have a plan to do something similar for physical machines – have a pool – be able to obtain one (or more), control the OS to revert to a snapshot etc.. but have some other things I need to accomplish first, and the extra snapshots will require UCS hardware and some SAN – yet to be determined.** ** ** ** /James ** ** *From:* jenkinsci-dev@googlegroups.com [mailto: jenkinsci-dev@googlegroups.com] *On Behalf Of *Jason Swager *Sent:* 07 August 2013 15:34 *To:* jenkinsci-dev@googlegroups.com *Subject:* Re: Persistent slave ** ** As far as I know, this isn't possible. The basic slave architecture requires a constant, unbroken connection to the slave. If the connection is broken, the build is considered a failure. There might be ways to handle this in the slave classes, but if there is, I'm not aware of them.* *** ** ** See this Stackoverflow Questionhttp://stackoverflow.com/questions/5543413/reconfigure-and-reboot-a-hudson-jenkins-slave-as-part-of-a-buildthat deals with the same issue. There are workarounds, but none quite as elegant as a rebootable slave. On Wednesday, August 7, 2013 7:18:17 AM UTC-7, Nickolay Rumyantsev wrote:* *** Hi! ** ** I am looking for a way to create a new kind of a slave (or a channel or smth) for defining a set of testing machines (virtual and real) in my jenkins. It must meet the following requirements: 1. It should provide additional states like: rebooting, broken, available (and probably some others). The logic of selecting the current state exists already and is related to tha testing process. 2. The job that is being executed on such kind of the slave should be tolerant to slave reboot (until the specified timeout is exceeded) so the build will proceed after reboot normally. I had a look a the exiting plugins and it looks for me that there is no similar plugin for now. ** ** Can you please tell me if is it possible and if it is so suggest what plugin can I take as a base or which extension points should I look at to start development? ** ** Thanks, Nickolay -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Persistent slave
nikolay, i forgot to mention that it does work across a reboot. it took me awhile but i finally figured it out with some help from a java guru (thanks jason) to get it to work. i really like this one because it works on demand and within a discrete step within the build process. xterm-one On Wed, Aug 7, 2013 at 10:43 AM, Phil Soliz phil.so...@gmail.com wrote: Hello Nikolay, i think that i might have a plugin to do what you want. i tried to add this plugin awhile back but didnt get a positive reply for its addition. the plugin name is vmware-esx-plugin and i built this so that i could revert the vm to a specific state, before or after the build, so that i could do repetitive testing. i would still like to add this plugin to the jenkins repo but i havent really pushed it. my username is xterm-one and its location is xterm-one/vmware-esx-plugin. i also had a bank of hardware machines that i used it on to revert to a specific state using a bootable cd (such as hiren) to revert to a specific state using ghost. xterm-one On Wed, Aug 7, 2013 at 10:17 AM, James Nord (jnord) jn...@cisco.comwrote: Hi Nickolay, ** ** For virtual you can somewhat accomplish this with the Cloudbees auto scaling plugin. ** ** You create a pool of virtual machines, and then assign one to your build which you can access via SSH. You can do whatever you want to to this VM as this VM is not the slave VM – although there are no additional states available. If you feel like coding then you could probably do something similar with the vSphere cloud plugin, or the labmanager plugin. ** ** I have a plan to do something similar for physical machines – have a pool – be able to obtain one (or more), control the OS to revert to a snapshot etc.. but have some other things I need to accomplish first, and the extra snapshots will require UCS hardware and some SAN – yet to be determined.* *** ** ** /James ** ** *From:* jenkinsci-dev@googlegroups.com [mailto: jenkinsci-dev@googlegroups.com] *On Behalf Of *Jason Swager *Sent:* 07 August 2013 15:34 *To:* jenkinsci-dev@googlegroups.com *Subject:* Re: Persistent slave ** ** As far as I know, this isn't possible. The basic slave architecture requires a constant, unbroken connection to the slave. If the connection is broken, the build is considered a failure. There might be ways to handle this in the slave classes, but if there is, I'm not aware of them. ** ** See this Stackoverflow Questionhttp://stackoverflow.com/questions/5543413/reconfigure-and-reboot-a-hudson-jenkins-slave-as-part-of-a-buildthat deals with the same issue. There are workarounds, but none quite as elegant as a rebootable slave. On Wednesday, August 7, 2013 7:18:17 AM UTC-7, Nickolay Rumyantsev wrote: Hi! ** ** I am looking for a way to create a new kind of a slave (or a channel or smth) for defining a set of testing machines (virtual and real) in my jenkins. It must meet the following requirements: 1. It should provide additional states like: rebooting, broken, available (and probably some others). The logic of selecting the current state exists already and is related to tha testing process. 2. The job that is being executed on such kind of the slave should be tolerant to slave reboot (until the specified timeout is exceeded) so the build will proceed after reboot normally. I had a look a the exiting plugins and it looks for me that there is no similar plugin for now. ** ** Can you please tell me if is it possible and if it is so suggest what plugin can I take as a base or which extension points should I look at to start development? ** ** Thanks, Nickolay -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Persistent slave
I would love to see a plugin that allowed a slave connection that persisted across reboot. On Wed, Aug 7, 2013 at 8:45 AM, Phil Soliz phil.so...@gmail.com wrote: nikolay, i forgot to mention that it does work across a reboot. it took me awhile but i finally figured it out with some help from a java guru (thanks jason) to get it to work. i really like this one because it works on demand and within a discrete step within the build process. xterm-one On Wed, Aug 7, 2013 at 10:43 AM, Phil Soliz phil.so...@gmail.com wrote: Hello Nikolay, i think that i might have a plugin to do what you want. i tried to add this plugin awhile back but didnt get a positive reply for its addition. the plugin name is vmware-esx-plugin and i built this so that i could revert the vm to a specific state, before or after the build, so that i could do repetitive testing. i would still like to add this plugin to the jenkins repo but i havent really pushed it. my username is xterm-one and its location is xterm-one/vmware-esx-plugin. i also had a bank of hardware machines that i used it on to revert to a specific state using a bootable cd (such as hiren) to revert to a specific state using ghost. xterm-one On Wed, Aug 7, 2013 at 10:17 AM, James Nord (jnord) jn...@cisco.comwrote: Hi Nickolay, ** ** For virtual you can somewhat accomplish this with the Cloudbees auto scaling plugin. ** ** You create a pool of virtual machines, and then assign one to your build which you can access via SSH. You can do whatever you want to to this VM as this VM is not the slave VM – although there are no additional states available. If you feel like coding then you could probably do something similar with the vSphere cloud plugin, or the labmanager plugin. ** ** I have a plan to do something similar for physical machines – have a pool – be able to obtain one (or more), control the OS to revert to a snapshot etc.. but have some other things I need to accomplish first, and the extra snapshots will require UCS hardware and some SAN – yet to be determined. ** ** /James ** ** *From:* jenkinsci-dev@googlegroups.com [mailto: jenkinsci-dev@googlegroups.com] *On Behalf Of *Jason Swager *Sent:* 07 August 2013 15:34 *To:* jenkinsci-dev@googlegroups.com *Subject:* Re: Persistent slave ** ** As far as I know, this isn't possible. The basic slave architecture requires a constant, unbroken connection to the slave. If the connection is broken, the build is considered a failure. There might be ways to handle this in the slave classes, but if there is, I'm not aware of them. ** ** See this Stackoverflow Questionhttp://stackoverflow.com/questions/5543413/reconfigure-and-reboot-a-hudson-jenkins-slave-as-part-of-a-buildthat deals with the same issue. There are workarounds, but none quite as elegant as a rebootable slave. On Wednesday, August 7, 2013 7:18:17 AM UTC-7, Nickolay Rumyantsev wrote: Hi! ** ** I am looking for a way to create a new kind of a slave (or a channel or smth) for defining a set of testing machines (virtual and real) in my jenkins. It must meet the following requirements: 1. It should provide additional states like: rebooting, broken, available (and probably some others). The logic of selecting the current state exists already and is related to tha testing process. 2. The job that is being executed on such kind of the slave should be tolerant to slave reboot (until the specified timeout is exceeded) so the build will proceed after reboot normally. I had a look a the exiting plugins and it looks for me that there is no similar plugin for now. ** ** Can you please tell me if is it possible and if it is so suggest what plugin can I take as a base or which extension points should I look at to start development? ** ** Thanks, Nickolay -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Marc MacIntyre -- You received this message because you are subscribed to the Google Groups
Plugin Installation trend not updated on the Jenkins wiki
Hi all, I was wondering if anyone could shed some light onto how often the plugin installation trend (http://stats.jenkins-ci.org/plugin-installation-trend/) is calculated and updated? It doesn't seem to cover the build-monitor-plugin ( https://wiki.jenkins-ci.org/display/JENKINS/Build+Monitor+Plugin) I released almost four weeks ago, so I'm not sure if that's related to some configuration somewhere I messed up or something else? Thanks in advance! Jan -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Persistent slave
Thanks for your replies! Unfortunately VMs are not in priority so the solution for real machines is needed first. Also the problem of host state reverting is out of scope for now. And what about Jenkins transport mechanizm - perhaps I could develop new implementation for hudson.remoting.VirtualChannel or something like this? At the moment I am not very familiar with Jenkins architecture. Regards, Nickolay среда, 7 августа 2013 г., 18:18:17 UTC+4 пользователь Nickolay Rumyantsev написал: Hi! I am looking for a way to create a new kind of a slave (or a channel or smth) for defining a set of testing machines (virtual and real) in my jenkins. It must meet the following requirements: 1. It should provide additional states like: rebooting, broken, available (and probably some others). The logic of selecting the current state exists already and is related to tha testing process. 2. The job that is being executed on such kind of the slave should be tolerant to slave reboot (until the specified timeout is exceeded) so the build will proceed after reboot normally. I had a look a the exiting plugins and it looks for me that there is no similar plugin for now. Can you please tell me if is it possible and if it is so suggest what plugin can I take as a base or which extension points should I look at to start development? Thanks, Nickolay -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [NOTICE] Credentials, SSH Credentials, SSH Agent and SSH Slaves
And someone just reported the same stacktrace on the users list with this ticket: JENKINS-19104 On Wed, Aug 7, 2013 at 11:22 AM, Larry Shatzer, Jr. lar...@gmail.comwrote: I'm now seeing this when it tries to connect to a SSH slave: http://pastebin.com/F5e9rTVX Also my windows slaves (setup as windows services via DCOM), are hanging on checking java version. I've now switched the critical slaves to be JNLP slaves, just to get it back up and working. On Wed, Aug 7, 2013 at 5:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of my improvements to the Credentials plugin I am pushing a whole new set of releases of these plugins. Credentials 1.6 is backwards compatible with all previous releases. It should be safe to upgrade that one on its own. SSH Credentials 1.0 requires Credentials 1.6 and includes a change to the on-disk data format. The consequence of this is that if you upgrade to SSH Credentials 1.0 you may loose credentials if you subsequently decide you made a mistake and decide to revert back to an earlier version... this is because the SSHUserPassword credentials have been migrated to the new StandardUsernamePasswordCredentials type in Credentials 1.6. This plugin is a new Major Version due to the deprecation of quite a few methods and classes. Note that if you do not upgrade SSH Slaves to a release that uses the new method signatures you may find that the Username/password credentials cannot be located. SSH Agent 1.2 requires SSH Credentials 1.0 and Credentials 1.6 but has no other impact. SSH Slaves 1.0 requires SSH Credentials 1.0 and Credentials 1.6. Given that this plugin is widely used, it advertises a change to the on-disk data format (despite there technically not being any) to prevent people accidentally upgrading without being aware that there is a potential impact (namely the changes in SSH Credentials 1.0) This version gets a new Major Version due to the major version change of SSH Credentials. I have done quite a bit of testing, and I am quite confident that the changes are safe... *but* you need to jump with all of them in one go, in other words IF you upgrade either of SSH Slaves or SSH Credentials to 1.0 you MUST ENSURE the other is upgraded also. Thanks for listening -Stephen -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [NOTICE] Credentials, SSH Credentials, SSH Agent and SSH Slaves
Did you ensure upgrading *all* three or just some of them.
If you go ssh credentials 1.0 or ssh slaves 1.0 you *must* do both
On Wednesday, 7 August 2013, Larry Shatzer, Jr. wrote:
And someone just reported the same stacktrace on the users list with this
ticket: JENKINS-19104
On Wed, Aug 7, 2013 at 11:22 AM, Larry Shatzer, Jr.
lar...@gmail.comjavascript:_e({}, 'cvml', 'lar...@gmail.com');
wrote:
I'm now seeing this when it tries to connect to a SSH slave:
http://pastebin.com/F5e9rTVX
Also my windows slaves (setup as windows services via DCOM), are hanging
on checking java version.
I've now switched the critical slaves to be JNLP slaves, just to get it
back up and working.
On Wed, Aug 7, 2013 at 5:54 AM, Stephen Connolly
stephen.alan.conno...@gmail.com javascript:_e({}, 'cvml',
'stephen.alan.conno...@gmail.com'); wrote:
As part of my improvements to the Credentials plugin I am pushing a
whole new set of releases of these plugins.
Credentials 1.6 is backwards compatible with all previous releases. It
should be safe to upgrade that one on its own.
SSH Credentials 1.0 requires Credentials 1.6 and includes a change to
the on-disk data format. The consequence of this is that if you upgrade to
SSH Credentials 1.0 you may loose credentials if you subsequently decide
you made a mistake and decide to revert back to an earlier version... this
is because the SSHUserPassword credentials have been migrated to the new
StandardUsernamePasswordCredentials type in Credentials 1.6. This plugin is
a new Major Version due to the deprecation of quite a few methods and
classes. Note that if you do not upgrade SSH Slaves to a release that uses
the new method signatures you may find that the Username/password
credentials cannot be located.
SSH Agent 1.2 requires SSH Credentials 1.0 and Credentials 1.6 but has
no other impact.
SSH Slaves 1.0 requires SSH Credentials 1.0 and Credentials 1.6. Given
that this plugin is widely used, it advertises a change to the on-disk data
format (despite there technically not being any) to prevent people
accidentally upgrading without being aware that there is a potential impact
(namely the changes in SSH Credentials 1.0) This version gets a new Major
Version due to the major version change of SSH Credentials.
I have done quite a bit of testing, and I am quite confident that the
changes are safe... *but* you need to jump with all of them in one go, in
other words
IF you upgrade either of SSH Slaves or SSH Credentials to 1.0 you MUST
ENSURE the other is upgraded also.
Thanks for listening
-Stephen
--
You received this message because you are subscribed to the Google
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.comjavascript:_e({},
'cvml', 'jenkinsci-dev%2bunsubscr...@googlegroups.com');
.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jenkinsci-dev+unsubscr...@googlegroups.com javascript:_e({},
'cvml', 'jenkinsci-dev%2bunsubscr...@googlegroups.com');.
For more options, visit https://groups.google.com/groups/opt_out.
--
Sent from my phone
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [NOTICE] Credentials, SSH Credentials, SSH Agent and SSH Slaves
I'm now seeing this when it tries to connect to a SSH slave: http://pastebin.com/F5e9rTVX Also my windows slaves (setup as windows services via DCOM), are hanging on checking java version. I've now switched the critical slaves to be JNLP slaves, just to get it back up and working. On Wed, Aug 7, 2013 at 5:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of my improvements to the Credentials plugin I am pushing a whole new set of releases of these plugins. Credentials 1.6 is backwards compatible with all previous releases. It should be safe to upgrade that one on its own. SSH Credentials 1.0 requires Credentials 1.6 and includes a change to the on-disk data format. The consequence of this is that if you upgrade to SSH Credentials 1.0 you may loose credentials if you subsequently decide you made a mistake and decide to revert back to an earlier version... this is because the SSHUserPassword credentials have been migrated to the new StandardUsernamePasswordCredentials type in Credentials 1.6. This plugin is a new Major Version due to the deprecation of quite a few methods and classes. Note that if you do not upgrade SSH Slaves to a release that uses the new method signatures you may find that the Username/password credentials cannot be located. SSH Agent 1.2 requires SSH Credentials 1.0 and Credentials 1.6 but has no other impact. SSH Slaves 1.0 requires SSH Credentials 1.0 and Credentials 1.6. Given that this plugin is widely used, it advertises a change to the on-disk data format (despite there technically not being any) to prevent people accidentally upgrading without being aware that there is a potential impact (namely the changes in SSH Credentials 1.0) This version gets a new Major Version due to the major version change of SSH Credentials. I have done quite a bit of testing, and I am quite confident that the changes are safe... *but* you need to jump with all of them in one go, in other words IF you upgrade either of SSH Slaves or SSH Credentials to 1.0 you MUST ENSURE the other is upgraded also. Thanks for listening -Stephen -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [NOTICE] Credentials, SSH Credentials, SSH Agent and SSH Slaves
I guess some of them were only in the update center, since I just found another after I forced it to check for new updates. It's restarting now. On Wed, Aug 7, 2013 at 11:30 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Did you ensure upgrading *all* three or just some of them. If you go ssh credentials 1.0 or ssh slaves 1.0 you *must* do both On Wednesday, 7 August 2013, Larry Shatzer, Jr. wrote: And someone just reported the same stacktrace on the users list with this ticket: JENKINS-19104 On Wed, Aug 7, 2013 at 11:22 AM, Larry Shatzer, Jr. lar...@gmail.comwrote: I'm now seeing this when it tries to connect to a SSH slave: http://pastebin.com/F5e9rTVX Also my windows slaves (setup as windows services via DCOM), are hanging on checking java version. I've now switched the critical slaves to be JNLP slaves, just to get it back up and working. On Wed, Aug 7, 2013 at 5:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of my improvements to the Credentials plugin I am pushing a whole new set of releases of these plugins. Credentials 1.6 is backwards compatible with all previous releases. It should be safe to upgrade that one on its own. SSH Credentials 1.0 requires Credentials 1.6 and includes a change to the on-disk data format. The consequence of this is that if you upgrade to SSH Credentials 1.0 you may loose credentials if you subsequently decide you made a mistake and decide to revert back to an earlier version... this is because the SSHUserPassword credentials have been migrated to the new StandardUsernamePasswordCredentials type in Credentials 1.6. This plugin is a new Major Version due to the deprecation of quite a few methods and classes. Note that if you do not upgrade SSH Slaves to a release that uses the new method signatures you may find that the Username/password credentials cannot be located. SSH Agent 1.2 requires SSH Credentials 1.0 and Credentials 1.6 but has no other impact. SSH Slaves 1.0 requires SSH Credentials 1.0 and Credentials 1.6. Given that this plugin is widely used, it advertises a change to the on-disk data format (despite there technically not being any) to prevent people accidentally upgrading without being aware that there is a potential impact (namely the changes in SSH Credentials 1.0) This version gets a new Major Version due to the major version change of SSH Credentials. I have done quite a bit of testing, and I am quite confident that the changes are safe... *but* you need to jump with all of them in one go, in other words IF you upgrade either of SSH Slaves or SSH Credentials to 1.0 you MUST ENSURE the other is upgraded also. Thanks for listening -Stephen -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Sent from my phone -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [NOTICE] Credentials, SSH Credentials, SSH Agent and SSH Slaves
Yeah Jenkins core is not smart enough to stop when it can't install the dependent plugins. Hopefully all should be good once you get all three updated. You could update the JIRA for me as I am on a smartphone for the rest of today! On Wednesday, 7 August 2013, Larry Shatzer, Jr. wrote: I guess some of them were only in the update center, since I just found another after I forced it to check for new updates. It's restarting now. On Wed, Aug 7, 2013 at 11:30 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Did you ensure upgrading *all* three or just some of them. If you go ssh credentials 1.0 or ssh slaves 1.0 you *must* do both On Wednesday, 7 August 2013, Larry Shatzer, Jr. wrote: And someone just reported the same stacktrace on the users list with this ticket: JENKINS-19104 On Wed, Aug 7, 2013 at 11:22 AM, Larry Shatzer, Jr. lar...@gmail.comwrote: I'm now seeing this when it tries to connect to a SSH slave: http://pastebin.com/F5e9rTVX Also my windows slaves (setup as windows services via DCOM), are hanging on checking java version. I've now switched the critical slaves to be JNLP slaves, just to get it back up and working. On Wed, Aug 7, 2013 at 5:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of my improvements to the Credentials plugin I am pushing a whole new set of releases of these plugins. Credentials 1.6 is backwards compatible with all previous releases. It should be safe to upgrade that one on its own. SSH Credentials 1.0 requires Credentials 1.6 and includes a change to the on-disk data format. The consequence of this is that if you upgrade to SSH Credentials 1.0 you may loose credentials if you subsequently decide you made a mistake and decide to revert back to an earlier version... this is because the SSHUserPassword credentials have been migrated to the new StandardUsernamePasswordCredentials type in Credentials 1.6. This plugin is a new Major Version due to the deprecation of quite a few methods and classes. Note that if you do not upgrade SSH Slaves to a release that uses the new method signatures you may find that the Username/password credentials cannot be located. SSH Agent 1.2 requires SSH Credentials 1.0 and Credentials 1.6 but has no other impact. SSH Slaves 1.0 requires SSH Credentials 1.0 and Credentials 1.6. Given that this plugin is widely used, it advertises a change to the on-disk data format (despite there technically not being any) to prevent people accidentally upgrading without being aware that there is a potential impact (namely the changes in SSH Credentials 1.0) This version gets a new Major Version due to the major version change of SSH Credentials. I have done quite a bit of testing, and I am quite confident that the changes are safe... *but* you need to jump with all of them in one go, in other words IF you upgrade either of SSH Slaves or SSH Credentials to 1.0 you MUST ENSURE the other is upgraded also. Thanks for listening -Stephen -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Sent from my phone -- You received this message because you are subscribed to the Google Groups Jenk -- Sent from my phone -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [NOTICE] Credentials, SSH Credentials, SSH Agent and SSH Slaves
Once all of the involved plugins were updated, all is well, except my windows slaves, but those are not as critical, and probably something else unrelated. I updated the jira ticket with a link to this thread, as well as the thread on the users list about it. -- Larry On Wed, Aug 7, 2013 at 11:35 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yeah Jenkins core is not smart enough to stop when it can't install the dependent plugins. Hopefully all should be good once you get all three updated. You could update the JIRA for me as I am on a smartphone for the rest of today! On Wednesday, 7 August 2013, Larry Shatzer, Jr. wrote: I guess some of them were only in the update center, since I just found another after I forced it to check for new updates. It's restarting now. On Wed, Aug 7, 2013 at 11:30 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Did you ensure upgrading *all* three or just some of them. If you go ssh credentials 1.0 or ssh slaves 1.0 you *must* do both On Wednesday, 7 August 2013, Larry Shatzer, Jr. wrote: And someone just reported the same stacktrace on the users list with this ticket: JENKINS-19104 On Wed, Aug 7, 2013 at 11:22 AM, Larry Shatzer, Jr. lar...@gmail.comwrote: I'm now seeing this when it tries to connect to a SSH slave: http://pastebin.com/F5e9rTVX Also my windows slaves (setup as windows services via DCOM), are hanging on checking java version. I've now switched the critical slaves to be JNLP slaves, just to get it back up and working. On Wed, Aug 7, 2013 at 5:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of my improvements to the Credentials plugin I am pushing a whole new set of releases of these plugins. Credentials 1.6 is backwards compatible with all previous releases. It should be safe to upgrade that one on its own. SSH Credentials 1.0 requires Credentials 1.6 and includes a change to the on-disk data format. The consequence of this is that if you upgrade to SSH Credentials 1.0 you may loose credentials if you subsequently decide you made a mistake and decide to revert back to an earlier version... this is because the SSHUserPassword credentials have been migrated to the new StandardUsernamePasswordCredentials type in Credentials 1.6. This plugin is a new Major Version due to the deprecation of quite a few methods and classes. Note that if you do not upgrade SSH Slaves to a release that uses the new method signatures you may find that the Username/password credentials cannot be located. SSH Agent 1.2 requires SSH Credentials 1.0 and Credentials 1.6 but has no other impact. SSH Slaves 1.0 requires SSH Credentials 1.0 and Credentials 1.6. Given that this plugin is widely used, it advertises a change to the on-disk data format (despite there technically not being any) to prevent people accidentally upgrading without being aware that there is a potential impact (namely the changes in SSH Credentials 1.0) This version gets a new Major Version due to the major version change of SSH Credentials. I have done quite a bit of testing, and I am quite confident that the changes are safe... *but* you need to jump with all of them in one go, in other words IF you upgrade either of SSH Slaves or SSH Credentials to 1.0 you MUST ENSURE the other is upgraded also. Thanks for listening -Stephen -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Sent from my phone -- You received this message because you are subscribed to the Google Groups Jenk -- Sent from my phone -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [NOTICE] Credentials, SSH Credentials, SSH Agent and SSH Slaves
Thanks On Wednesday, 7 August 2013, Larry Shatzer, Jr. wrote: Once all of the involved plugins were updated, all is well, except my windows slaves, but those are not as critical, and probably something else unrelated. I updated the jira ticket with a link to this thread, as well as the thread on the users list about it. -- Larry On Wed, Aug 7, 2013 at 11:35 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yeah Jenkins core is not smart enough to stop when it can't install the dependent plugins. Hopefully all should be good once you get all three updated. You could update the JIRA for me as I am on a smartphone for the rest of today! On Wednesday, 7 August 2013, Larry Shatzer, Jr. wrote: I guess some of them were only in the update center, since I just found another after I forced it to check for new updates. It's restarting now. On Wed, Aug 7, 2013 at 11:30 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Did you ensure upgrading *all* three or just some of them. If you go ssh credentials 1.0 or ssh slaves 1.0 you *must* do both On Wednesday, 7 August 2013, Larry Shatzer, Jr. wrote: And someone just reported the same stacktrace on the users list with this ticket: JENKINS-19104 On Wed, Aug 7, 2013 at 11:22 AM, Larry Shatzer, Jr. lar...@gmail.comwrote: I'm now seeing this when it tries to connect to a SSH slave: http://pastebin.com/F5e9rTVX Also my windows slaves (setup as windows services via DCOM), are hanging on checking java version. I've now switched the critical slaves to be JNLP slaves, just to get it back up and working. On Wed, Aug 7, 2013 at 5:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of my improvements to the Credentials plugin I am pushing a whole new set of releases of these plugins. Credentials 1.6 is backwards compatible with all previous releases. It should be safe to upgrade that one on its own. SSH Credentials 1.0 requires Credentials 1.6 and includes a change to the on-disk data format. The consequence of this is that if you upgrade to SSH Credentials 1.0 you may loose credentials if you subsequently decide you made a mistake and decide to revert back to an earlier version... this is because the SSHUserPassword credentials have been migrated to the new StandardUsernamePasswordCredentials type in Credentials 1.6. This plugin is a new Major Version due to the deprecation of quite a few methods and classes. Note that if you do not upgrade SSH Slaves to a release that uses the new method signatures you may find that the Username/password credentials cannot be located. SSH Agent 1.2 requires SSH Credentials 1.0 and Credentials 1.6 but has no other impact. SSH Slaves 1.0 requires SSH Credentials 1.0 and Credentials 1.6. Given that this plugin is widely used, it advertises a change to the on-disk data format (despite there technically not being any) to prevent people accidentally upgrading without being aware that there is a potential impact (namely the changes in SSH Credentials 1.0) This version gets a new Major Version due to the major version change of SSH Credentials. I have done quite a bit of testing, and I am quite confident that the changes are safe... *but* you need to jump with all of them in one go, in other words IF you upgrade either of SSH Slaves or SSH Credentials to 1.0 you MUST ENSURE the other is upgraded also. Thanks for listening -Stephen -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Sent from my phone -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [NOTICE] Credentials, SSH Credentials, SSH Agent and SSH Slaves
Yeah I might not have needed the notice if I could rely on that being fixed. It's also why I want to get these three ducks lined up for 1.509.4 (so that everyone gets the correct bundled versions) and I will be pushing into a new HEAD version soon. There are other plugins that need these changes (e.g. subversion, etc) and it will be easier to prevent issues for customers if we have a stable baseline of 1.6, 1.0 and 1.0 On 7 August 2013 19:23, Kohsuke Kawaguchi kkawagu...@cloudbees.com wrote: https://issues.jenkins-ci.org/**browse/JENKINS-18608https://issues.jenkins-ci.org/browse/JENKINS-18608 Looks like we need to fix this soon to reduce the damage. On 08/07/2013 10:35 AM, Stephen Connolly wrote: Yeah Jenkins core is not smart enough to stop when it can't install the dependent plugins. Hopefully all should be good once you get all three updated. You could update the JIRA for me as I am on a smartphone for the rest of today! On Wednesday, 7 August 2013, Larry Shatzer, Jr. wrote: I guess some of them were only in the update center, since I just found another after I forced it to check for new updates. It's restarting now. On Wed, Aug 7, 2013 at 11:30 AM, Stephen Connolly stephen.alan.connolly@gmail.**com stephen.alan.conno...@gmail.com wrote: Did you ensure upgrading *all* three or just some of them. If you go ssh credentials 1.0 or ssh slaves 1.0 you *must* do both On Wednesday, 7 August 2013, Larry Shatzer, Jr. wrote: And someone just reported the same stacktrace on the users list with this ticket: JENKINS-19104 On Wed, Aug 7, 2013 at 11:22 AM, Larry Shatzer, Jr. lar...@gmail.com wrote: I'm now seeing this when it tries to connect to a SSH slave: http://pastebin.com/F5e9rTVX Also my windows slaves (setup as windows services via DCOM), are hanging on checking java version. I've now switched the critical slaves to be JNLP slaves, just to get it back up and working. On Wed, Aug 7, 2013 at 5:54 AM, Stephen Connolly stephen.alan.connolly@gmail.**comstephen.alan.conno...@gmail.com wrote: As part of my improvements to the Credentials plugin I am pushing a whole new set of releases of these plugins. Credentials 1.6 is backwards compatible with all previous releases. It should be safe to upgrade that one on its own. SSH Credentials 1.0 requires Credentials 1.6 and includes a change to the on-disk data format. The consequence of this is that if you upgrade to SSH Credentials 1.0 you may loose credentials if you subsequently decide you made a mistake and decide to revert back to an earlier version... this is because the SSHUserPassword credentials have been migrated to the new StandardUsernamePasswordCreden**tials type in Credentials 1.6. This plugin is a new Major Version due to the deprecation of quite a few methods and classes. Note that if you do not upgrade SSH Slaves to a release that uses the new method signatures you may find that the Username/password credentials cannot be located. SSH Agent 1.2 requires SSH Credentials 1.0 and Credentials 1.6 but has no other impact. SSH Slaves 1.0 requires SSH Credentials 1.0 and Credentials 1.6. Given that this plugin is widely used, it advertises a change to the on-disk data format (despite there technically not being any) to prevent people accidentally upgrading without being aware that there is a potential impact (namely the changes in SSH Credentials 1.0) This version gets a new Major Version due to the major version change of SSH Credentials. I have done quite a bit of testing, and I am quite confident that the changes are safe... *but* you need to jump with all of them in one go, in other words IF you upgrade either of SSH Slaves or SSH Credentials to 1.0 you MUST ENSURE the other is upgraded also. Thanks for listening -Stephen -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To
Re: [NOTICE] Credentials, SSH Credentials, SSH Agent and SSH Slaves
The fix to https://issues.jenkins-ci.org/browse/JENKINS-19104 is in version 1.1 of the ssh-credentials plugin. Only affects people using private keys. You can download it from http://jenkins-updates.cloudbees.com/download/plugins/ssh-credentials/1.1/ssh-credentials.hpiif you are waiting for it to show up in the OSS update center. On 7 August 2013 18:23, Larry Shatzer, Jr. lar...@gmail.com wrote: And someone just reported the same stacktrace on the users list with this ticket: JENKINS-19104 On Wed, Aug 7, 2013 at 11:22 AM, Larry Shatzer, Jr. lar...@gmail.comwrote: I'm now seeing this when it tries to connect to a SSH slave: http://pastebin.com/F5e9rTVX Also my windows slaves (setup as windows services via DCOM), are hanging on checking java version. I've now switched the critical slaves to be JNLP slaves, just to get it back up and working. On Wed, Aug 7, 2013 at 5:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of my improvements to the Credentials plugin I am pushing a whole new set of releases of these plugins. Credentials 1.6 is backwards compatible with all previous releases. It should be safe to upgrade that one on its own. SSH Credentials 1.0 requires Credentials 1.6 and includes a change to the on-disk data format. The consequence of this is that if you upgrade to SSH Credentials 1.0 you may loose credentials if you subsequently decide you made a mistake and decide to revert back to an earlier version... this is because the SSHUserPassword credentials have been migrated to the new StandardUsernamePasswordCredentials type in Credentials 1.6. This plugin is a new Major Version due to the deprecation of quite a few methods and classes. Note that if you do not upgrade SSH Slaves to a release that uses the new method signatures you may find that the Username/password credentials cannot be located. SSH Agent 1.2 requires SSH Credentials 1.0 and Credentials 1.6 but has no other impact. SSH Slaves 1.0 requires SSH Credentials 1.0 and Credentials 1.6. Given that this plugin is widely used, it advertises a change to the on-disk data format (despite there technically not being any) to prevent people accidentally upgrading without being aware that there is a potential impact (namely the changes in SSH Credentials 1.0) This version gets a new Major Version due to the major version change of SSH Credentials. I have done quite a bit of testing, and I am quite confident that the changes are safe... *but* you need to jump with all of them in one go, in other words IF you upgrade either of SSH Slaves or SSH Credentials to 1.0 you MUST ENSURE the other is upgraded also. Thanks for listening -Stephen -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Newbie problem: can't merge my own PR
Hi, Maybe this is newbie problem, but I can't merge my own PR. I've made PR https://github.com/jenkinsci/redmine-plugin/pull/11 but somehow I'm not seeing green button Merge pull request. Fun thing is that I can merge other people PR in different repos - I see mentioned earlier green button :). As note I'm member of jenkinsci organization on github. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
