Re: New Plugin: Liquibase Runner
Sorry, due to the renaming of the repo the granted group has been renamed too. Can you please retry? Am 25.04.2014 um 23:27 schrieb Keith Collison keithc...@gmail.com: Perhaps I'm missing something, but I don't seem to be able to commit to this repository: remote: Permission to jenkinsci/liquibase-runner-plugin.git denied to prospero238. fatal: unable to access 'https://github.com/jenkinsci/liquibase-runner-plugin.git/': The requested URL returned error: 403 Please advise. Thank you in advance! ~ Keith On Friday, April 25, 2014 11:40:20 AM UTC-7, Ullrich Hafner wrote: Done: https://github.com/jenkinsci/liquibase-runner-plugin/ Am 25.04.2014 um 20:21 schrieb Keith Collison keit...@gmail.com: The repository was indeed created (I gather that this was done perhaps by a bot). However, the repository name seems a little funky, having two dashes at the end of it (liquibase-runner-plugin--). While I'm sure this is merely cosmetic, if there's a way to lop off those two dashes, I'd be pleased. In addition (and no doubt more importantly), I don't seem to be able to push to this repository. Running git push yields: Push failed: fatal: unable to access 'https://github.com/jenkinsci/liquibase-runner-plugin--.git/': The requested URL returned error: 403 Let me know if I'm doing something bone-headed. Thank you. ~ Keith On Thursday, April 24, 2014 1:46:26 PM UTC-7, Dominik Bartholdi wrote: At least the repo exists - don't know if someone else created it... Am 24.04.2014 um 21:01 schrieb Ulli Hafner ullrich...@gmail.com: Ah, did it actually work? The bot didn’t actually send a response… Am 24.04.2014 um 20:49 schrieb Dominik Bartholdi do...@fortysix.ch: This seems already to be forked… Domi On 24.04.2014, at 00:10, Keith Collison keit...@gmail.com wrote: Greetings esteemed Jenkinists: I have created a Jenkins Plugin and, per instructions on the wiki, I am notifying this mailing list as to its existence. Details: Jenkins Plugin Name: liquibase-runner Current Location: https://github.com/prospero238/liquibase-runner Github User: prospero238 Jenkins-ci org account: prospero238 (yes, same name as my github user). My understanding is that my current repo will be forked. Further, I can looked forward to its inclusion in the Cloudbees CI environment. I'll be happy to create a wiki page once this is done (or, if it standard to this beforehand, happy to do that as well). As this is my first plugin, I welcome comments and suggestions about the code, as well as my conduct. Let me know what is required of me to move forward. Kind Regards, Keith -- 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/d/optout. -- 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/d/optout. -- 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/d/optout. -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: New plugin (TestFairy) Hosting and Repository Request
On 25.04.2014, at 06:06, Christopher Orr ch...@orr.me.uk wrote: Stupid question: if a plugin is relying on a fix or feature that was backported to 1.509.3, what happens to users running 1.510 which, presumably, does not have that fix/feature? Not a stupid question. I don't think there's a way to make this work properly (e.g. define a version requirement of must have 1.509.3 or 1.519). From my POV there are a few mitigating factors though: - Only important (to LTS use) API is backported, so it should be a rare enough occurrence. - It only affects the versions between an LTS release and a weekly before the next LTS -- 6 versions in the worst case (assuming the new 12 week LTS cycle). - If you're not on LTS, chances are you're updating more frequently than once a quarter, making use of old non-LTS versions unlikely. There are fewer installations on 1.510-1.518 (missing RunAction2) than are using the latest weekly version within a week of its release. - Updating your regular release after encountering an error after a plugin installation or update (likely on startup) will fix it. - It'll take a while for your use of new API in a new plugin (in the case of the archetype) to reach users. -- 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/d/optout.
New plugin request: send-to-eclipse
We have developed a plugin which can send a stacktrace of a failing testcase to Eclipse. In Eclipse you need a plugin, which can receive the request. The Eclipse plugin can be found here: http://cbos.github.io/OpenFromExternalEvent/ *Jenkins Plugin Name:* send-to-eclipse-plugin https://github.com/prospero238/liquibase-runner *Github User:* cbos *Jenkins-ci org account:* cbos Regards, Cees -- 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/d/optout.
Re: New Plugin: Liquibase Runner
The repository was indeed created (I gather that this was done perhaps by a bot). However, the repository name seems a little funky, having two dashes at the end of it (liquibase-runner-plugin--). While I'm sure this is merely cosmetic, if there's a way to lop off those two dashes, I'd be pleased. In addition (and no doubt more importantly), I don't seem to be able to push to this repository. Running git push yields: Push failed: fatal: unable to access 'https://github.com/jenkinsci/liquibase-runner-plugin--.git/': The requested URL returned error: 403 Let me know if I'm doing something bone-headed. Thank you. ~ Keith On Thursday, April 24, 2014 1:46:26 PM UTC-7, Dominik Bartholdi wrote: At least the repo exists - don't know if someone else created it... Am 24.04.2014 um 21:01 schrieb Ulli Hafner ullrich...@gmail.comjavascript: : Ah, did it actually work? The bot didn’t actually send a response… Am 24.04.2014 um 20:49 schrieb Dominik Bartholdi do...@fortysix.chjavascript: : This seems already to be forked… Domi On 24.04.2014, at 00:10, Keith Collison keit...@gmail.com javascript: wrote: Greetings esteemed Jenkinists: I have created a Jenkins Plugin and, per instructions on the wiki, I am notifying this mailing list as to its existence. Details: *Jenkins Plugin Name:* liquibase-runner *Current Location:* https://github.com/prospero238/liquibase-runnerhttps://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fcmester%2FTestFairysa=Dsntz=1usg=AFQjCNGIziF_sBWN04MTGVLzKj89-3nwFQ *Github User:* prospero238 *Jenkins-ci org account:* prospero238 (yes, same name as my github user). My understanding is that my current repo will be forked. Further, I can looked forward to its inclusion in the Cloudbees CI environment. I'll be happy to create a wiki page once this is done (or, if it standard to this beforehand, happy to do that as well). As this is my first plugin, I welcome comments and suggestions about the code, as well as my conduct. Let me know what is required of me to move forward. Kind Regards, Keith -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
Re: New Plugin: Liquibase Runner
Done: https://github.com/jenkinsci/liquibase-runner-plugin/ Am 25.04.2014 um 20:21 schrieb Keith Collison keithc...@gmail.com: The repository was indeed created (I gather that this was done perhaps by a bot). However, the repository name seems a little funky, having two dashes at the end of it (liquibase-runner-plugin--). While I'm sure this is merely cosmetic, if there's a way to lop off those two dashes, I'd be pleased. In addition (and no doubt more importantly), I don't seem to be able to push to this repository. Running git push yields: Push failed: fatal: unable to access 'https://github.com/jenkinsci/liquibase-runner-plugin--.git/': The requested URL returned error: 403 Let me know if I'm doing something bone-headed. Thank you. ~ Keith On Thursday, April 24, 2014 1:46:26 PM UTC-7, Dominik Bartholdi wrote: At least the repo exists - don't know if someone else created it... Am 24.04.2014 um 21:01 schrieb Ulli Hafner ullrich...@gmail.com: Ah, did it actually work? The bot didn’t actually send a response… Am 24.04.2014 um 20:49 schrieb Dominik Bartholdi do...@fortysix.ch: This seems already to be forked… Domi On 24.04.2014, at 00:10, Keith Collison keit...@gmail.com wrote: Greetings esteemed Jenkinists: I have created a Jenkins Plugin and, per instructions on the wiki, I am notifying this mailing list as to its existence. Details: Jenkins Plugin Name: liquibase-runner Current Location: https://github.com/prospero238/liquibase-runner Github User: prospero238 Jenkins-ci org account: prospero238 (yes, same name as my github user). My understanding is that my current repo will be forked. Further, I can looked forward to its inclusion in the Cloudbees CI environment. I'll be happy to create a wiki page once this is done (or, if it standard to this beforehand, happy to do that as well). As this is my first plugin, I welcome comments and suggestions about the code, as well as my conduct. Let me know what is required of me to move forward. Kind Regards, Keith -- 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/d/optout. -- 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/d/optout. -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: New Plugin: Liquibase Runner
Perhaps I'm missing something, but I don't seem to be able to commit to this repository: remote: Permission to jenkinsci/liquibase-runner-plugin.git denied to prospero238. fatal: unable to access 'https://github.com/jenkinsci/liquibase-runner-plugin.git/': The requested URL returned error: 403 Please advise. Thank you in advance! ~ Keith On Friday, April 25, 2014 11:40:20 AM UTC-7, Ullrich Hafner wrote: Done: https://github.com/jenkinsci/liquibase-runner-plugin/ Am 25.04.2014 um 20:21 schrieb Keith Collison keit...@gmail.comjavascript: : The repository was indeed created (I gather that this was done perhaps by a bot). However, the repository name seems a little funky, having two dashes at the end of it (liquibase-runner-plugin--). While I'm sure this is merely cosmetic, if there's a way to lop off those two dashes, I'd be pleased. In addition (and no doubt more importantly), I don't seem to be able to push to this repository. Running git push yields: Push failed: fatal: unable to access ' https://github.com/jenkinsci/liquibase-runner-plugin--.git/': The requested URL returned error: 403 Let me know if I'm doing something bone-headed. Thank you. ~ Keith On Thursday, April 24, 2014 1:46:26 PM UTC-7, Dominik Bartholdi wrote: At least the repo exists - don't know if someone else created it... Am 24.04.2014 um 21:01 schrieb Ulli Hafner ullrich...@gmail.com: Ah, did it actually work? The bot didn’t actually send a response… Am 24.04.2014 um 20:49 schrieb Dominik Bartholdi do...@fortysix.ch: This seems already to be forked… Domi On 24.04.2014, at 00:10, Keith Collison keit...@gmail.com wrote: Greetings esteemed Jenkinists: I have created a Jenkins Plugin and, per instructions on the wiki, I am notifying this mailing list as to its existence. Details: *Jenkins Plugin Name:* liquibase-runner *Current Location:* https://github.com/prospero238/liquibase-runnerhttps://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fcmester%2FTestFairysa=Dsntz=1usg=AFQjCNGIziF_sBWN04MTGVLzKj89-3nwFQ *Github User:* prospero238 *Jenkins-ci org account:* prospero238 (yes, same name as my github user). My understanding is that my current repo will be forked. Further, I can looked forward to its inclusion in the Cloudbees CI environment. I'll be happy to create a wiki page once this is done (or, if it standard to this beforehand, happy to do that as well). As this is my first plugin, I welcome comments and suggestions about the code, as well as my conduct. Let me know what is required of me to move forward. Kind Regards, Keith -- 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/d/optout. -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
Re: Unable to push :-( (Re: New Plugin 'Artifact Promotion' / hosting request)
Can you please retry? Am 24.04.2014 um 10:58 schrieb Halil-Cem Gürsoy hcguer...@gmail.com: Hi Ulli, I'm unable to push into the repo :-( $ ~/Development/default/scm/artifact-promotion$ git push origin master Username for 'https://github.com': hcguersoy Password for 'https://hcguer...@github.com': remote: Permission to jenkinsci/artifact-promotion-plugin.git denied to hcguersoy. fatal: unable to access 'https://github.com/jenkinsci/artifact-promotion-plugin.git/': The requested URL returned error: 403 I can see in my profile that I'm now member of Jenkins CI and that I was assigned as developer to this repo. Any suggestions? Thanks in advance Halil Am Mittwoch, 9. April 2014 23:24:33 UTC+2 schrieb Ullrich Hafner: Sorry for the delay: https://github.com/jenkinsci/artifact-promotion-plugin Welcome aboard! Ulli Am 08.04.2014 um 09:51 schrieb Halil-Cem Gürsoy hcgu...@gmail.com: *bump* Did I missed something in my initial request? -- 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/d/optout. -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Unable to push :-( (Re: New Plugin 'Artifact Promotion' / hosting request)
Works fine now! Thanks for your immediate help! Am Donnerstag, 24. April 2014 11:43:55 UTC+2 schrieb Ullrich Hafner: Can you please retry? Am 24.04.2014 um 10:58 schrieb Halil-Cem Gürsoy hcgu...@gmail.comjavascript: : Hi Ulli, I'm unable to push into the repo :-( $ ~/Development/default/scm/artifact-promotion$ git push origin master Username for 'https://github.com': hcguersoy Password for 'https://hcguer...@github.com': remote: Permission to jenkinsci/artifact-promotion-plugin.git denied to hcguersoy. fatal: unable to access ' https://github.com/jenkinsci/artifact-promotion-plugin.git/': The requested URL returned error: 403 I can see in my profile that I'm now member of Jenkins CI and that I was assigned as developer to this repo. Any suggestions? Thanks in advance Halil Am Mittwoch, 9. April 2014 23:24:33 UTC+2 schrieb Ullrich Hafner: Sorry for the delay: https://github.com/jenkinsci/artifact-promotion-plugin Welcome aboard! Ulli Am 08.04.2014 um 09:51 schrieb Halil-Cem Gürsoy hcgu...@gmail.com: *bump* Did I missed something in my initial request? -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
Re: New Plugin: Liquibase Runner
This seems already to be forked... Domi On 24.04.2014, at 00:10, Keith Collison keithc...@gmail.com wrote: Greetings esteemed Jenkinists: I have created a Jenkins Plugin and, per instructions on the wiki, I am notifying this mailing list as to its existence. Details: Jenkins Plugin Name: liquibase-runner Current Location: https://github.com/prospero238/liquibase-runner Github User: prospero238 Jenkins-ci org account: prospero238 (yes, same name as my github user). My understanding is that my current repo will be forked. Further, I can looked forward to its inclusion in the Cloudbees CI environment. I'll be happy to create a wiki page once this is done (or, if it standard to this beforehand, happy to do that as well). As this is my first plugin, I welcome comments and suggestions about the code, as well as my conduct. Let me know what is required of me to move forward. Kind Regards, Keith -- 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/d/optout. -- 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/d/optout.
Re: New Plugin: Liquibase Runner
Ah, did it actually work? The bot didn’t actually send a response… Am 24.04.2014 um 20:49 schrieb Dominik Bartholdi d...@fortysix.ch: This seems already to be forked… Domi On 24.04.2014, at 00:10, Keith Collison keithc...@gmail.com wrote: Greetings esteemed Jenkinists: I have created a Jenkins Plugin and, per instructions on the wiki, I am notifying this mailing list as to its existence. Details: Jenkins Plugin Name: liquibase-runner Current Location: https://github.com/prospero238/liquibase-runner Github User: prospero238 Jenkins-ci org account: prospero238 (yes, same name as my github user). My understanding is that my current repo will be forked. Further, I can looked forward to its inclusion in the Cloudbees CI environment. I'll be happy to create a wiki page once this is done (or, if it standard to this beforehand, happy to do that as well). As this is my first plugin, I welcome comments and suggestions about the code, as well as my conduct. Let me know what is required of me to move forward. Kind Regards, Keith -- 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/d/optout. -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: New Plugin: Liquibase Runner
At least the repo exists - don't know if someone else created it... Am 24.04.2014 um 21:01 schrieb Ulli Hafner ullrich.haf...@gmail.com: Ah, did it actually work? The bot didn’t actually send a response… Am 24.04.2014 um 20:49 schrieb Dominik Bartholdi d...@fortysix.ch: This seems already to be forked… Domi On 24.04.2014, at 00:10, Keith Collison keithc...@gmail.com wrote: Greetings esteemed Jenkinists: I have created a Jenkins Plugin and, per instructions on the wiki, I am notifying this mailing list as to its existence. Details: Jenkins Plugin Name: liquibase-runner Current Location: https://github.com/prospero238/liquibase-runner Github User: prospero238 Jenkins-ci org account: prospero238 (yes, same name as my github user). My understanding is that my current repo will be forked. Further, I can looked forward to its inclusion in the Cloudbees CI environment. I'll be happy to create a wiki page once this is done (or, if it standard to this beforehand, happy to do that as well). As this is my first plugin, I welcome comments and suggestions about the code, as well as my conduct. Let me know what is required of me to move forward. Kind Regards, Keith -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
Re: New plugin (TestFairy) Hosting and Repository Request
On 04/23/2014 10:55 PM, Christopher Orr wrote: On 04/23/2014 09:45 PM, Jesse Glick wrote: On Wed, Apr 23, 2014 at 8:24 AM, Christopher Orr ch...@orr.me.uk wrote: I think you probably want to set the minimum Jenkins version to 1.509 rather than 1.509.4. It is up to the plugin dev, but I find it useful to specify an LTS branch tip version rather than the correspondingly weekly branch point as a baseline because: · Sometimes backported fixes necessarily included small new APIs, and these can be important to make sure your plugin takes advantage of a fix in core or a framework provided in core to let plugins avoid a class of problem. RunAction2, backported to 1.509.3, is an example: it is very important to use this, and it is not in 1.509. Stupid question: if a plugin is relying on a fix or feature that was backported to 1.509.3, what happens to users running 1.510 which, presumably, does not have that fix/feature? Thanks, Chris -- 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/d/optout.
Re: New Plugin 'Artifact Promotion' / hosting request
Hi James, I know - but this is functionality is only available with Nexus Pro. Many are using the free Nexus without this functionality. This applies to the metadata in nexus (AFAIK the metadata plugin was removed) and artifactory, too. Am Donnerstag, 10. April 2014 10:20:17 UTC+2 schrieb James Nord (jnord): BTW – there is code in the m2release plugin to control nexus pro stages. /James *From:* jenkin...@googlegroups.com javascript: [mailto: jenkin...@googlegroups.com javascript:] *On Behalf Of *Ulli Hafner *Sent:* 09 April 2014 22:25 *To:* jenkin...@googlegroups.com javascript: *Subject:* Re: New Plugin 'Artifact Promotion' / hosting request Sorry for the delay: https://github.com/jenkinsci/artifact-promotion-plugin Welcome aboard! Ulli Am 08.04.2014 um 09:51 schrieb Halil-Cem Gürsoy hcgu...@gmail.comjavascript: : *bump* Did I missed something in my initial request? -- 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/d/optout. -- 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/d/optout.
Re: New Plugin 'Artifact Promotion' / hosting request
Thanks! Am Mittwoch, 9. April 2014 23:24:33 UTC+2 schrieb Ullrich Hafner: Sorry for the delay: https://github.com/jenkinsci/artifact-promotion-plugin Welcome aboard! Ulli Am 08.04.2014 um 09:51 schrieb Halil-Cem Gürsoy hcgu...@gmail.comjavascript: : *bump* Did I missed something in my initial request? -- 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/d/optout. -- 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/d/optout.
New plugin (TestFairy) Hosting and Repository Request
Hi, We've created a Jenkins plugin, it performs Android apk uploads to https://www.testfairy.com/ as a post build step. Could you please create hosting and fork my github jenkins plugin? *Jenkins Plugin Name:* TestFairy *Current Location:* https://github.com/cmester/TestFairy *Our GitHub Users:* cmester, icotora, io3pg *My JenkinsCI User:* jenkins3pillar Thank you! Ciprian PS: deleted the previous post since it had no public repo and it was created via a distribution list -- 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/d/optout.
Re: New plugin (TestFairy) Hosting and Repository Request
Done: https://github.com/jenkinsci/testfairy-plugin Am 23.04.2014 um 10:04 schrieb Ciprian Mester ciprian.mes...@3pillarglobal.com: Hi, We've created a Jenkins plugin, it performs Android apk uploads to https://www.testfairy.com/ as a post build step. Could you please create hosting and fork my github jenkins plugin? Jenkins Plugin Name: TestFairy Current Location: https://github.com/cmester/TestFairy Our GitHub Users: cmester, icotora, io3pg My JenkinsCI User: jenkins3pillar Thank you! Ciprian PS: deleted the previous post since it had no public repo and it was created via a distribution list -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: New plugin (TestFairy) Hosting and Repository Request
I think you probably want to set the minimum Jenkins version to 1.509 rather than 1.509.4. On 23/04/14 13:15, Ulli Hafner wrote: Done: https://github.com/jenkinsci/testfairy-plugin Am 23.04.2014 um 10:04 schrieb Ciprian Mester ciprian.mes...@3pillarglobal.com mailto:ciprian.mes...@3pillarglobal.com: Hi, We've created a Jenkins plugin, it performs Android apk uploads to https://www.testfairy.com/ as a post build step. Could you please create hosting and fork my github jenkins plugin? *Jenkins Plugin Name:* TestFairy *Current Location:* https://github.com/cmester/TestFairy *Our GitHub Users:* cmester, icotora, io3pg *My JenkinsCI User:* jenkins3pillar Thank you! Ciprian PS: deleted the previous post since it had no public repo and it was created via a distribution list -- 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 mailto:jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout.
Re: New plugin Perforce
Unless I've missed a post, can someone tell me what's currently wrong with the current plugin that warrants a pretty much from the ground up new plugin? Speaking as a heavy user of Perforce if people are currently using the existing plugin what issues are people having? What worries me is that the current plugin has been through its cycle of real world usage for bug finding, a new plugin to me means that cycle has to happen again. Like I say, I'm curious what's being brought to the table here, I'd hate to see the current plugin go stale as it's the only reason we're currently using Jenkins at all is because it's one of the few CIs that have streamed depots working out of the box. -- 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/d/optout.
Re: New plugin Perforce
Hi Niksan, The Jenkins plugin had popped up on Perforce's radar a few times; often for performance issues. With our new Swarm tool we wanted a better Continuous Build experience and needed to update the plugin. Starting that process we identified a few issues: 1. Maintainability - It's old/deprecated; large portions are based on Hudson not Jenkins 2. Efficiency - Slow and inefficient use for workspaces and sync 3. Perforce API - New plugin will support P4Java and not the command wrapper 4. ExtensionPoints - Split the code base into multiple extension points for clarity 5. Shelving Support - Allow shelving for building code reviews before submit 6. Credentials - Support Jenkins Credentials for managing many jobs The current plan is to release the two plugins in parallel, allowing users to try out the new plugin. Then migrating the old to new plugin over a few releases to smooth over any rough edges. Shelving is already in and we hope to add many of the new features available in Perforce. If you have any specific concerns or feature you would like, do please let us know. Kind regards, Paul On 23 Apr 2014, at 14:26, Niksan sumot...@googlemail.com wrote: Unless I've missed a post, can someone tell me what's currently wrong with the current plugin that warrants a pretty much from the ground up new plugin? Speaking as a heavy user of Perforce if people are currently using the existing plugin what issues are people having? What worries me is that the current plugin has been through its cycle of real world usage for bug finding, a new plugin to me means that cycle has to happen again. Like I say, I'm curious what's being brought to the table here, I'd hate to see the current plugin go stale as it's the only reason we're currently using Jenkins at all is because it's one of the few CIs that have streamed depots working out of the box. -- 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/d/optout. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Perforce Software. Finally, the recipient should check this email and any attachments for the presence of viruses. Perforce Software accepts no liability for any damage caused by any virus transmitted by this email. Perforce Software UK Ltd is registered in England and Wales as company no. 3816019 at the following address: West Forest Gate, Wellington Road, Wokingham, RG40 2AT, UK -- 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/d/optout.
Re: New plugin Perforce
I don't have have any issues with the current plugin bar a few cosmetic fixes that can be overcome by using groovy the issues are mainly with p4 itself but you have your own forum where we highlight those. :) My biggest concern is the onus to keep the current plugin in development when a known replacement is on its way. In regards to your points, 1 and 3 pretty much boil down to the same thing. Point 2 I've not personally seen and I'm not sure how a sync can be more efficient than calling p4 sync, as for efficient use of workspaces you'd have to elaborate on that. Point 6 I've no idea how that would make it easier to manage many jobs but interested to hear. Point 5 seems like something that could easily be added to the existing plugin. Point 3, this is the big one for me, I'm an advocate for using a command line wrapper in regards to Perforce, this is with experience of using the .NET API and the fact the APIs are closed source so you're at mercy to what the API provides, you don't have this issue using the command line wrappers and in general you have more power at your hands without the need for the API to be fixed or expose functionality. I may be in a minority on the point above, I just have concerns that when it comes to new features, P4Api will get in the way. On Wednesday, April 23, 2014 2:58:32 PM UTC+1, pallen wrote: Hi Niksan, The Jenkins plugin had popped up on Perforce's radar a few times; often for performance issues. With our new Swarm tool we wanted a better Continuous Build experience and needed to update the plugin. Starting that process we identified a few issues: 1. Maintainability - It's old/deprecated; large portions are based on Hudson not Jenkins 2. Efficiency- Slow and inefficient use for workspaces and sync 3. Perforce API- New plugin will support P4Java and not the command wrapper 4. ExtensionPoints- Split the code base into multiple extension points for clarity 5. Shelving Support- Allow shelving for building code reviews before submit 6. Credentials- Support Jenkins Credentials for managing many jobs The current plan is to release the two plugins in parallel, allowing users to try out the new plugin. Then migrating the old to new plugin over a few releases to smooth over any rough edges. Shelving is already in and we hope to add many of the new features available in Perforce. If you have any specific concerns or feature you would like, do please let us know. Kind regards, Paul On 23 Apr 2014, at 14:26, Niksan sumo...@googlemail.com javascript: wrote: Unless I've missed a post, can someone tell me what's currently wrong with the current plugin that warrants a pretty much from the ground up new plugin? Speaking as a heavy user of Perforce if people are currently using the existing plugin what issues are people having? What worries me is that the current plugin has been through its cycle of real world usage for bug finding, a new plugin to me means that cycle has to happen again. Like I say, I'm curious what's being brought to the table here, I'd hate to see the current plugin go stale as it's the only reason we're currently using Jenkins at all is because it's one of the few CIs that have streamed depots working out of the box. -- 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/d/optout. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Perforce Software. Finally, the recipient should check this email and any attachments for the presence of viruses. Perforce Software accepts no liability for any damage caused by any virus transmitted by this email. Perforce Software UK Ltd is registered in England and Wales as company no. 3816019 at the following address: West Forest Gate, Wellington Road, Wokingham, RG40 2AT, UK -- 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/d/optout.
Re: New plugin Perforce
I meant point 1 and 4 are the same, not point 1 and 3. :) -- 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/d/optout.
Re: New plugin Perforce
Hi Niksan, On 23 Apr 2014, at 15:48, Niksan sumot...@googlemail.com wrote: Point 3, this is the big one for me, I'm an advocate for using a command line wrapper in regards to Perforce, this is with experience of using the .NET API and the fact the APIs are closed source so you're at mercy to what the API provides, you don't have this issue using the command line wrappers and in general you have more power at your hands without the need for the API to be fixed or expose functionality. I may be in a minority on the point above, I just have concerns that when it comes to new features, P4Api will get in the way. You will be pleased to hear that the .NET API is now open source and p4-java is in the process of being opened. They are on our Workshop: https://swarm.workshop.perforce.com/projects/perforce-software-p4api-net/ Paul This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Perforce Software. Finally, the recipient should check this email and any attachments for the presence of viruses. Perforce Software accepts no liability for any damage caused by any virus transmitted by this email. Perforce Software UK Ltd is registered in England and Wales as company no. 3816019 at the following address: West Forest Gate, Wellington Road, Wokingham, RG40 2AT, UK -- 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/d/optout.
Re: New plugin (TestFairy) Hosting and Repository Request
On Wed, Apr 23, 2014 at 8:24 AM, Christopher Orr ch...@orr.me.uk wrote: I think you probably want to set the minimum Jenkins version to 1.509 rather than 1.509.4. It is up to the plugin dev, but I find it useful to specify an LTS branch tip version rather than the correspondingly weekly branch point as a baseline because: · Sometimes backported fixes necessarily included small new APIs, and these can be important to make sure your plugin takes advantage of a fix in core or a framework provided in core to let plugins avoid a class of problem. RunAction2, backported to 1.509.3, is an example: it is very important to use this, and it is not in 1.509. · LTS fixes can introduce various behavioral changes which may affect how your plugin runs. When you are using automated testing (JUnit) or interactive testing (mvn hpi:run), you would prefer to see your plugin’s behavior in the context of the most recent core version possible, without making the baseline be so new as to actually exclude intended users. Of course there will be some potential users who, for example, intentionally stuck with 1.509.2 or 1.509.3 and declined to upgrade to 1.509.4. But I think these would be a fairly small minority. Also there will be a few people running obsolete weekly builds newer than the branch point but lacking an API backported to LTS (for example 1.510, in the case of RunAction2); and Jenkins lacks the ability to notice that your plugin is not compatible with such a build. Again I think the number of potential users running an old weekly build should be small: most people would either pick an LTS line and keep up with it, or be running fairly recent weekly builds. -- 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/d/optout.
Re: New plugin (TestFairy) Hosting and Repository Request
On 04/23/2014 09:45 PM, Jesse Glick wrote: On Wed, Apr 23, 2014 at 8:24 AM, Christopher Orr ch...@orr.me.uk wrote: I think you probably want to set the minimum Jenkins version to 1.509 rather than 1.509.4. It is up to the plugin dev, but I find it useful to specify an LTS branch tip version rather than the correspondingly weekly branch point as a baseline because: · Sometimes backported fixes necessarily included small new APIs, and these can be important to make sure your plugin takes advantage of a fix in core or a framework provided in core to let plugins avoid a class of problem. RunAction2, backported to 1.509.3, is an example: it is very important to use this, and it is not in 1.509. Ahh, ok. Fair point! Chris -- 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/d/optout.
Re: New plugin Perforce
Hi Steve, Thanks for your reply, I have added comments below... [Steve RE: Credentials] The new plugin extends Jenkins Credentials into two new types. Perforce Password credential and Perforce Ticket credential; these both support SSL and P4TRUST finger prints. I did look at the password and SSL credentials, but Perforce has some specifics P4TICKETS etc.. Sounds like you've implemented one too many. You should not be implementing a user+pass credential type at all. The ticket credential type is fair enough... In principle (I have not looked at your code mind) I may have taken the use of your credentials too far, but it makes a very neat solution for Perforce authentication. We can even extend the pattern to Perforce cert based SSO later. Do try it out if you have a moment or I can send a screen shot if you are interested. We try to discourage the user of passwords from a security perspective and encourage our users to use session tickets. Tickets are bound to a connection, this is why I store the Perforce connection. I also allows users to test the credential with the validate button. I had tried to make the SCM polling more efficient and letting Perforce manage it's own workspaces, after all this is what Perforce was designed to do. I was not aware of the 'SCM-API', is there any docs/guide like: https://wiki.jenkins-ci.org/display/JENKINS/SCM+plugin+architecture No docs yet. It's needed to allow multi-branch support ala literate project type (though no limited to literate) Subversion, git and hg all have implementations of the SCM-api. It impacts polling as you want to expand the scope of what you find info about, so eg * subversion maintains a map of latest revisions of various paths... This map will in future be used to reduce the amount of polling that jobs need... At present only literate takes advantage of the map (waiting until I feel the credentials support has bedded down) * git and hg maintain a local checkout which (git) can be used / (hg) is used to speed up checkout on slaves and reduce the amount of querying Once SCM-api us fully integrated these plugins will have effectively much more performant polling whereby eg push notifications get merged into local stores so that 99% of polling operations are served from a local cache (fed by both other jobs off same repo and push notifications) I'll take a look at your code/implementations when I'm back in the office, so I can understand if this polling is needed this way in Perforce. Perforce is unique in the way that stores (server side) a lot of information about what is in a client's workspace. Kind regards, Paul This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Perforce Software. Finally, the recipient should check this email and any attachments for the presence of viruses. Perforce Software accepts no liability for any damage caused by any virus transmitted by this email. Perforce Software UK Ltd is registered in England and Wales as company no. 3816019 at the following address: West Forest Gate, Wellington Road, Wokingham, RG40 2AT, UK -- 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/d/optout.
Re: New plugin Perforce
Hi Guys, Sorry I han't been checking email over the Easter break. I like Kohsuke Kawaguchi's idea of running the two together, it will allow user to try out the now plugin and provide feedback. I'm not sure how easy it would be to provide a migration path for each Build Job's configuration, but this would simplify adoption. ... Just seen Jesse's post; perhaps I don't appreciate the differences. Allowing the two code bases to co-exist (effectively two plugins in one). The UI can than just show Perforce-1 / Perforce-2; as we progress this could change to Perforce-Deprecated / Perforce, then finally just Perforce. [Steve RE: Credentials] The new plugin extends Jenkins Credentials into two new types. Perforce Password credential and Perforce Ticket credential; these both support SSL and P4TRUST finger prints. I did look at the password and SSL credentials, but Perforce has some specifics P4TICKETS etc.. I had tried to make the SCM polling more efficient and letting Perforce manage it's own workspaces, after all this is what Perforce was designed to do. I was not aware of the 'SCM-API', is there any docs/guide like: https://wiki.jenkins-ci.org/display/JENKINS/SCM+plugin+architecture As Oleg mentioned there are features that I haven't had time to port; these shouldn't take long but I would like to involve the community and especially the authors. I'm back in on Tuesday; will try and keep an eye on the posts... Thank you all for your involvement, I'm pleased there is so much interest and help. Kind regards, Paul On 18 Apr 2014, at 18:46, Rob Petti rob.pe...@gmail.com wrote: I didn't realize that you could release two versions of a plugin at the same time to two different update centers. I think your proposal is probably the best option here. On Fri, Apr 18, 2014 at 11:31 AM, Kohsuke Kawaguchi kkawagu...@cloudbees.com wrote: I'm waiting for Rob and Paul to agree on the approach forward. I think we'd be happy to honor that, since you guys are the ones that are doing the actual work. Where Jesse and I are coming from is to try to understand the message to the existing users, because Perforce plugin is widely used. If you expect both current and new plugins to co-exist going forward, that's the least preferable outcome from users' PoV. The next better one is that you expect the current plugin to become dormant and all the efforts to go to the new plugin. It's still disruptive for users, but at least there's a clarity in the direction. The next better one is that you two agree that the current plugin will become dormant and the new one will take over, then we work out the data migration compatibility between the current and new plugin, without preserving code compatibility. This is pretty good for users, as they don't have to go through disruptive changes. Then the final one is to try to maintain some/all of the code compatibility. If there are plugin out there that depends on the perforce plugin, this will make their users happy. Without much experience of Perforce, what I'd like to encourage you to consider is the third option, and here is one way of doing it. We could put both current and the new in the same repo, and call the new one perforce plugin 2.0. They need not share the code at all. 2.0 would work toward feature parity with 1.0. Existing Jenkins devs can help create migration shim in the 2.0 branch. We can have alpha/beta releases of 2.0 in parallel to updates to 1.x releases. People on the beta update center will get this 2.0 beta versions. When 2.0 is in feature parity, we can have the official 2.0 release. Or if we discover that feature parity is unattainable, we can rename the new version to another name and release it as a separate plugin. On 04/18/2014 02:33 AM, Paul Allen wrote: Hi Rob, The refactoring effort would be so wide spread there would be very little, if anything, left. By removing the underlying p4 command wrapper (Tek42) and replacing it with the p4-java api would require a re-write of all the functions. In addition the behavioural changes to the use of Perforce workspaces and authentication would change most of the user interface. I suggest that we either create a new plugin 'p4' or fork/rename the existing plugin. A new plugin would be less disruptive to the existing user base and give the opportunity for a clean start. Paul On 17 Apr 2014, at 19:23, Rob Petti rob.pe...@gmail.com wrote: I thought it was decided that refactoring the old plugin was the better way to go? It's less of an impact on users, and preserves all of the required functionality. If not, then just make a new repo, I guess... On Thursday, 17 April 2014 10:52:20 UTC-6, pallen wrote: I have been discussing the plugin for sometime over email. I'll CC Rob and the others... Paul On 17 Apr 2014, at 16:59, Jesse Glick jgl...@cloudbees.com
Re: New plugin Perforce
I had tried to make the SCM polling more efficient and letting Perforce manage it's own workspaces, after all this is what Perforce was designed to do. Can you please explain this statement? Perforce has always forced the user to manage workspaces by hand, and is a major pain point for any sort of automation. If you mean using the build workspace to determine if there are any changes, this won't work for several reasons, which is why the current plugin implements polling by tracking and comparing the latest changeset number. On Sun, Apr 20, 2014 at 7:42 AM, Paul Allen pal...@perforce.com wrote: Hi Guys, Sorry I han't been checking email over the Easter break. I like Kohsuke Kawaguchi's idea of running the two together, it will allow user to try out the now plugin and provide feedback. I'm not sure how easy it would be to provide a migration path for each Build Job's configuration, but this would simplify adoption. ... Just seen Jesse's post; perhaps I don't appreciate the differences. Allowing the two code bases to co-exist (effectively two plugins in one). The UI can than just show Perforce-1 / Perforce-2; as we progress this could change to Perforce-Deprecated / Perforce, then finally just Perforce. [Steve RE: Credentials] The new plugin extends Jenkins Credentials into two new types. Perforce Password credential and Perforce Ticket credential; these both support SSL and P4TRUST finger prints. I did look at the password and SSL credentials, but Perforce has some specifics P4TICKETS etc.. I had tried to make the SCM polling more efficient and letting Perforce manage it's own workspaces, after all this is what Perforce was designed to do. I was not aware of the 'SCM-API', is there any docs/guide like: https://wiki.jenkins-ci.org/display/JENKINS/SCM+plugin+architecture As Oleg mentioned there are features that I haven't had time to port; these shouldn't take long but I would like to involve the community and especially the authors. I'm back in on Tuesday; will try and keep an eye on the posts... Thank you all for your involvement, I'm pleased there is so much interest and help. Kind regards, Paul On 18 Apr 2014, at 18:46, Rob Petti rob.pe...@gmail.com wrote: I didn't realize that you could release two versions of a plugin at the same time to two different update centers. I think your proposal is probably the best option here. On Fri, Apr 18, 2014 at 11:31 AM, Kohsuke Kawaguchi kkawagu...@cloudbees.com wrote: I'm waiting for Rob and Paul to agree on the approach forward. I think we'd be happy to honor that, since you guys are the ones that are doing the actual work. Where Jesse and I are coming from is to try to understand the message to the existing users, because Perforce plugin is widely used. If you expect both current and new plugins to co-exist going forward, that's the least preferable outcome from users' PoV. The next better one is that you expect the current plugin to become dormant and all the efforts to go to the new plugin. It's still disruptive for users, but at least there's a clarity in the direction. The next better one is that you two agree that the current plugin will become dormant and the new one will take over, then we work out the data migration compatibility between the current and new plugin, without preserving code compatibility. This is pretty good for users, as they don't have to go through disruptive changes. Then the final one is to try to maintain some/all of the code compatibility. If there are plugin out there that depends on the perforce plugin, this will make their users happy. Without much experience of Perforce, what I'd like to encourage you to consider is the third option, and here is one way of doing it. We could put both current and the new in the same repo, and call the new one perforce plugin 2.0. They need not share the code at all. 2.0 would work toward feature parity with 1.0. Existing Jenkins devs can help create migration shim in the 2.0 branch. We can have alpha/beta releases of 2.0 in parallel to updates to 1.x releases. People on the beta update center will get this 2.0 beta versions. When 2.0 is in feature parity, we can have the official 2.0 release. Or if we discover that feature parity is unattainable, we can rename the new version to another name and release it as a separate plugin. On 04/18/2014 02:33 AM, Paul Allen wrote: Hi Rob, The refactoring effort would be so wide spread there would be very little, if anything, left. By removing the underlying p4 command wrapper (Tek42) and replacing it with the p4-java api would require a re-write of all the functions. In addition the behavioural changes to the use of Perforce workspaces and authentication would change most of the user interface. I suggest that we either create a new plugin 'p4' or fork/rename the existing plugin. A new plugin would
Re: New plugin Perforce
On Sunday, 20 April 2014, Paul Allen pal...@perforce.com wrote: Hi Guys, Sorry I han't been checking email over the Easter break. I like Kohsuke Kawaguchi's idea of running the two together, it will allow user to try out the now plugin and provide feedback. I'm not sure how easy it would be to provide a migration path for each Build Job's configuration, but this would simplify adoption. ... Just seen Jesse's post; perhaps I don't appreciate the differences. Allowing the two code bases to co-exist (effectively two plugins in one). The UI can than just show Perforce-1 / Perforce-2; as we progress this could change to Perforce-Deprecated / Perforce, then finally just Perforce. [Steve RE: Credentials] The new plugin extends Jenkins Credentials into two new types. Perforce Password credential and Perforce Ticket credential; these both support SSL and P4TRUST finger prints. I did look at the password and SSL credentials, but Perforce has some specifics P4TICKETS etc.. Sounds like you've implemented one too many. You should not be implementing a user+pass credential type at all. The ticket credential type is fair enough... In principle (I have not looked at your code mind) I had tried to make the SCM polling more efficient and letting Perforce manage it's own workspaces, after all this is what Perforce was designed to do. I was not aware of the 'SCM-API', is there any docs/guide like: https://wiki.jenkins-ci.org/display/JENKINS/SCM+plugin+architecture No docs yet. It's needed to allow multi-branch support ala literate project type (though no limited to literate) Subversion, git and hg all have implementations of the SCM-api. It impacts polling as you want to expand the scope of what you find info about, so eg * subversion maintains a map of latest revisions of various paths... This map will in future be used to reduce the amount of polling that jobs need... At present only literate takes advantage of the map (waiting until I feel the credentials support has bedded down) * git and hg maintain a local checkout which (git) can be used / (hg) is used to speed up checkout on slaves and reduce the amount of querying Once SCM-api us fully integrated these plugins will have effectively much more performant polling whereby eg push notifications get merged into local stores so that 99% of polling operations are served from a local cache (fed by both other jobs off same repo and push notifications) As Oleg mentioned there are features that I haven't had time to port; these shouldn't take long but I would like to involve the community and especially the authors. I'm back in on Tuesday; will try and keep an eye on the posts... Thank you all for your involvement, I'm pleased there is so much interest and help. Kind regards, Paul On 18 Apr 2014, at 18:46, Rob Petti rob.pe...@gmail.com wrote: I didn't realize that you could release two versions of a plugin at the same time to two different update centers. I think your proposal is probably the best option here. On Fri, Apr 18, 2014 at 11:31 AM, Kohsuke Kawaguchi kkawagu...@cloudbees.com wrote: I'm waiting for Rob and Paul to agree on the approach forward. I think we'd be happy to honor that, since you guys are the ones that are doing the actual work. Where Jesse and I are coming from is to try to understand the message to the existing users, because Perforce plugin is widely used. If you expect both current and new plugins to co-exist going forward, that's the least preferable outcome from users' PoV. The next better one is that you expect the current plugin to become dormant and all the efforts to go to the new plugin. It's still disruptive for users, but at least there's a clarity in the direction. The next better one is that you two agree that the current plugin will become dormant and the new one will take over, then we work out the data migration compatibility between the current and new plugin, without preserving code compatibility. This is pretty good for users, as they don't have to go through disruptive changes. Then the final one is to try to maintain some/all of the code compatibility. If there are plugin out there that depends on the perforce plugin, this will make their users happy. Without much experience of Perforce, what I'd like to encourage you to consider is the third option, and here is one way of doing it. We could put both current and the new in the same repo, and call the new one perforce plugin 2.0. They need not share the code at all. 2.0 would work toward feature parity with 1.0. Existing Jenkins devs can help create migration shim in the 2.0 branch. We can have alpha/beta releases of 2.0 in parallel to updates to 1.x releases. People on the beta update center will get this 2.0 beta versions. When 2.0 is in feature parity, we can have the official 2.0 release. Or if we discover that feature parity is unattainable
Re: New plugin Perforce
I'm just putting those two things out there as it is better to integrate credentials from the beginning... and a smart SCM-API implementation can be leveraged to deliver better polling support for regular job types... which again calls for early integration. You probably don't need P4 specific credential type. You should be able to get away with a Domain requirements/specification and the standard username/password credentials type On 18 April 2014 11:55, Oleg Nenashev o.v.nenas...@gmail.com wrote: @Stephen Yes, of course. In the case of the legacy plugin refactoring there will be a P4CredentialsProvider extension point, which will have the implementation for Credentials Plugin ( https://github.com/jenkinsci/perforce-plugin/pull/45). AFAIK, Paul has implemented the integration in his plugin PoC. SCM-API would be useful as well. The real issue is an approach to be used... - Paul (from the Perforce SCM vendor) wants to create a new plugin and to sacrifice some features from the previous one. - Seems that other discussion participants (including me) prefer the refactoring approach with a smooth migration for users. - From my side, the Perforce plugin is relatively stable, so there is no urgent need to spend many man-weeks to integrate all required features to the new plugin and to migrate existing jobs. Nobody wants to waste his efforts, hence the maintenance/development of the original Perforce plugin just hangs. This plugin definitely requires a major refactoring (the Hudson compatibility has been maintained for a long time, so there is no support of tasty Jenkins features), so we definitely need to select a way to move forward. BR, Oleg Nenashev 2014-04-18 13:42 GMT+04:00 Stephen Connolly stephen.alan.conno...@gmail.com: hope you are integrating with the credentials and the scm-api plugins On 18 April 2014 10:33, Paul Allen pal...@perforce.com wrote: Hi Rob, The refactoring effort would be so wide spread there would be very little, if anything, left. By removing the underlying p4 command wrapper (Tek42) and replacing it with the p4-java api would require a re-write of all the functions. In addition the behavioural changes to the use of Perforce workspaces and authentication would change most of the user interface. I suggest that we either create a new plugin 'p4' or fork/rename the existing plugin. A new plugin would be less disruptive to the existing user base and give the opportunity for a clean start. Paul On 17 Apr 2014, at 19:23, Rob Petti rob.pe...@gmail.com wrote: I thought it was decided that refactoring the old plugin was the better way to go? It's less of an impact on users, and preserves all of the required functionality. If not, then just make a new repo, I guess... On Thursday, 17 April 2014 10:52:20 UTC-6, pallen wrote: I have been discussing the plugin for sometime over email. I'll CC Rob and the others... Paul On 17 Apr 2014, at 16:59, Jesse Glick jgl...@cloudbees.com wrote: On Thu, Apr 17, 2014 at 11:51 AM, Paul Allen pal...@perforce.com wrote: Whilst the new plugin provides all the basic SCM functions, it is not yet as feature rich. We plan to add features [...] [...] perhaps there is a way to branch (fork) the old codebase into a legacy area? A bit more work, but arguably better for users, would be to include the new refactored implementation inside the existing plugin (in trunk versions). For a time, users of the plugin would see two SCM options--Perforce (v1) and Perforce (v2)--with somewhat different configuration UIs and functionality. They could experiment with switching to v2, or go back for a while, on a project-by-project basis. You could even decide that v1 configurations restricted to a certain set of commonly used features would be safe to automatically upgrade (i.e., readResolve) to a v2 configuration. Eventually the v1 implementation could be dropped, or rather exist only as a class with a readResolve method. This is of course assuming that the current maintainer(s) of perforce-plugin are aware of your effort and on board with it. -- 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/d/optout. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Perforce Software
Re: New plugin Perforce
You probably don't need P4 specific credential type. You should be able to get away with a Domain requirements/specification and the standard username/password credentials type You are right, but such migration requires 1.509.x to be a minimal supported version. The proposed PR has been created in away, which allows to retain the current minimal version (with an external implementation of Credentials) If we start the development of Perforce 2.0, all existing approaches should be re-considered together with other community members. 2014-04-18 15:28 GMT+04:00 Stephen Connolly stephen.alan.conno...@gmail.com : I'm just putting those two things out there as it is better to integrate credentials from the beginning... and a smart SCM-API implementation can be leveraged to deliver better polling support for regular job types... which again calls for early integration. You probably don't need P4 specific credential type. You should be able to get away with a Domain requirements/specification and the standard username/password credentials type On 18 April 2014 11:55, Oleg Nenashev o.v.nenas...@gmail.com wrote: @Stephen Yes, of course. In the case of the legacy plugin refactoring there will be a P4CredentialsProvider extension point, which will have the implementation for Credentials Plugin ( https://github.com/jenkinsci/perforce-plugin/pull/45). AFAIK, Paul has implemented the integration in his plugin PoC. SCM-API would be useful as well. The real issue is an approach to be used... - Paul (from the Perforce SCM vendor) wants to create a new plugin and to sacrifice some features from the previous one. - Seems that other discussion participants (including me) prefer the refactoring approach with a smooth migration for users. - From my side, the Perforce plugin is relatively stable, so there is no urgent need to spend many man-weeks to integrate all required features to the new plugin and to migrate existing jobs. Nobody wants to waste his efforts, hence the maintenance/development of the original Perforce plugin just hangs. This plugin definitely requires a major refactoring (the Hudson compatibility has been maintained for a long time, so there is no support of tasty Jenkins features), so we definitely need to select a way to move forward. BR, Oleg Nenashev 2014-04-18 13:42 GMT+04:00 Stephen Connolly stephen.alan.conno...@gmail.com: hope you are integrating with the credentials and the scm-api plugins On 18 April 2014 10:33, Paul Allen pal...@perforce.com wrote: Hi Rob, The refactoring effort would be so wide spread there would be very little, if anything, left. By removing the underlying p4 command wrapper (Tek42) and replacing it with the p4-java api would require a re-write of all the functions. In addition the behavioural changes to the use of Perforce workspaces and authentication would change most of the user interface. I suggest that we either create a new plugin 'p4' or fork/rename the existing plugin. A new plugin would be less disruptive to the existing user base and give the opportunity for a clean start. Paul On 17 Apr 2014, at 19:23, Rob Petti rob.pe...@gmail.com wrote: I thought it was decided that refactoring the old plugin was the better way to go? It's less of an impact on users, and preserves all of the required functionality. If not, then just make a new repo, I guess... On Thursday, 17 April 2014 10:52:20 UTC-6, pallen wrote: I have been discussing the plugin for sometime over email. I'll CC Rob and the others... Paul On 17 Apr 2014, at 16:59, Jesse Glick jgl...@cloudbees.com wrote: On Thu, Apr 17, 2014 at 11:51 AM, Paul Allen pal...@perforce.com wrote: Whilst the new plugin provides all the basic SCM functions, it is not yet as feature rich. We plan to add features [...] [...] perhaps there is a way to branch (fork) the old codebase into a legacy area? A bit more work, but arguably better for users, would be to include the new refactored implementation inside the existing plugin (in trunk versions). For a time, users of the plugin would see two SCM options--Perforce (v1) and Perforce (v2)--with somewhat different configuration UIs and functionality. They could experiment with switching to v2, or go back for a while, on a project-by-project basis. You could even decide that v1 configurations restricted to a certain set of commonly used features would be safe to automatically upgrade (i.e., readResolve) to a v2 configuration. Eventually the v1 implementation could be dropped, or rather exist only as a class with a readResolve method. This is of course assuming that the current maintainer(s) of perforce-plugin are aware of your effort and on board with it. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop
Re: New plugin Perforce
I'm waiting for Rob and Paul to agree on the approach forward. I think we'd be happy to honor that, since you guys are the ones that are doing the actual work. Where Jesse and I are coming from is to try to understand the message to the existing users, because Perforce plugin is widely used. If you expect both current and new plugins to co-exist going forward, that's the least preferable outcome from users' PoV. The next better one is that you expect the current plugin to become dormant and all the efforts to go to the new plugin. It's still disruptive for users, but at least there's a clarity in the direction. The next better one is that you two agree that the current plugin will become dormant and the new one will take over, then we work out the data migration compatibility between the current and new plugin, without preserving code compatibility. This is pretty good for users, as they don't have to go through disruptive changes. Then the final one is to try to maintain some/all of the code compatibility. If there are plugin out there that depends on the perforce plugin, this will make their users happy. Without much experience of Perforce, what I'd like to encourage you to consider is the third option, and here is one way of doing it. We could put both current and the new in the same repo, and call the new one perforce plugin 2.0. They need not share the code at all. 2.0 would work toward feature parity with 1.0. Existing Jenkins devs can help create migration shim in the 2.0 branch. We can have alpha/beta releases of 2.0 in parallel to updates to 1.x releases. People on the beta update center will get this 2.0 beta versions. When 2.0 is in feature parity, we can have the official 2.0 release. Or if we discover that feature parity is unattainable, we can rename the new version to another name and release it as a separate plugin. On 04/18/2014 02:33 AM, Paul Allen wrote: Hi Rob, The refactoring effort would be so wide spread there would be very little, if anything, left. By removing the underlying p4 command wrapper (Tek42) and replacing it with the p4-java api would require a re-write of all the functions. In addition the behavioural changes to the use of Perforce workspaces and authentication would change most of the user interface. I suggest that we either create a new plugin 'p4' or fork/rename the existing plugin. A new plugin would be less disruptive to the existing user base and give the opportunity for a clean start. Paul On 17 Apr 2014, at 19:23, Rob Petti rob.pe...@gmail.com wrote: I thought it was decided that refactoring the old plugin was the better way to go? It's less of an impact on users, and preserves all of the required functionality. If not, then just make a new repo, I guess... On Thursday, 17 April 2014 10:52:20 UTC-6, pallen wrote: I have been discussing the plugin for sometime over email. I'll CC Rob and the others... Paul On 17 Apr 2014, at 16:59, Jesse Glick jgl...@cloudbees.com wrote: On Thu, Apr 17, 2014 at 11:51 AM, Paul Allen pal...@perforce.com wrote: Whilst the new plugin provides all the basic SCM functions, it is not yet as feature rich. We plan to add features [...] [...] perhaps there is a way to branch (fork) the old codebase into a legacy area? A bit more work, but arguably better for users, would be to include the new refactored implementation inside the existing plugin (in trunk versions). For a time, users of the plugin would see two SCM options--Perforce (v1) and Perforce (v2)--with somewhat different configuration UIs and functionality. They could experiment with switching to v2, or go back for a while, on a project-by-project basis. You could even decide that v1 configurations restricted to a certain set of commonly used features would be safe to automatically upgrade (i.e., readResolve) to a v2 configuration. Eventually the v1 implementation could be dropped, or rather exist only as a class with a readResolve method. This is of course assuming that the current maintainer(s) of perforce-plugin are aware of your effort and on board with it. -- 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/d/optout. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Perforce Software. Finally, the recipient should check this email and any attachments for the presence of viruses
Re: New plugin Perforce
I didn't realize that you could release two versions of a plugin at the same time to two different update centers. I think your proposal is probably the best option here. On Fri, Apr 18, 2014 at 11:31 AM, Kohsuke Kawaguchi kkawagu...@cloudbees.com wrote: I'm waiting for Rob and Paul to agree on the approach forward. I think we'd be happy to honor that, since you guys are the ones that are doing the actual work. Where Jesse and I are coming from is to try to understand the message to the existing users, because Perforce plugin is widely used. If you expect both current and new plugins to co-exist going forward, that's the least preferable outcome from users' PoV. The next better one is that you expect the current plugin to become dormant and all the efforts to go to the new plugin. It's still disruptive for users, but at least there's a clarity in the direction. The next better one is that you two agree that the current plugin will become dormant and the new one will take over, then we work out the data migration compatibility between the current and new plugin, without preserving code compatibility. This is pretty good for users, as they don't have to go through disruptive changes. Then the final one is to try to maintain some/all of the code compatibility. If there are plugin out there that depends on the perforce plugin, this will make their users happy. Without much experience of Perforce, what I'd like to encourage you to consider is the third option, and here is one way of doing it. We could put both current and the new in the same repo, and call the new one perforce plugin 2.0. They need not share the code at all. 2.0 would work toward feature parity with 1.0. Existing Jenkins devs can help create migration shim in the 2.0 branch. We can have alpha/beta releases of 2.0 in parallel to updates to 1.x releases. People on the beta update center will get this 2.0 beta versions. When 2.0 is in feature parity, we can have the official 2.0 release. Or if we discover that feature parity is unattainable, we can rename the new version to another name and release it as a separate plugin. On 04/18/2014 02:33 AM, Paul Allen wrote: Hi Rob, The refactoring effort would be so wide spread there would be very little, if anything, left. By removing the underlying p4 command wrapper (Tek42) and replacing it with the p4-java api would require a re-write of all the functions. In addition the behavioural changes to the use of Perforce workspaces and authentication would change most of the user interface. I suggest that we either create a new plugin 'p4' or fork/rename the existing plugin. A new plugin would be less disruptive to the existing user base and give the opportunity for a clean start. Paul On 17 Apr 2014, at 19:23, Rob Petti rob.pe...@gmail.com wrote: I thought it was decided that refactoring the old plugin was the better way to go? It's less of an impact on users, and preserves all of the required functionality. If not, then just make a new repo, I guess... On Thursday, 17 April 2014 10:52:20 UTC-6, pallen wrote: I have been discussing the plugin for sometime over email. I'll CC Rob and the others... Paul On 17 Apr 2014, at 16:59, Jesse Glick jgl...@cloudbees.com wrote: On Thu, Apr 17, 2014 at 11:51 AM, Paul Allen pal...@perforce.com wrote: Whilst the new plugin provides all the basic SCM functions, it is not yet as feature rich. We plan to add features [...] [...] perhaps there is a way to branch (fork) the old codebase into a legacy area? A bit more work, but arguably better for users, would be to include the new refactored implementation inside the existing plugin (in trunk versions). For a time, users of the plugin would see two SCM options--Perforce (v1) and Perforce (v2)--with somewhat different configuration UIs and functionality. They could experiment with switching to v2, or go back for a while, on a project-by-project basis. You could even decide that v1 configurations restricted to a certain set of commonly used features would be safe to automatically upgrade (i.e., readResolve) to a v2 configuration. Eventually the v1 implementation could be dropped, or rather exist only as a class with a readResolve method. This is of course assuming that the current maintainer(s) of perforce-plugin are aware of your effort and on board with it. -- 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/d/optout. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have
Re: New plugin Perforce
On Fri, Apr 18, 2014 at 1:31 PM, Kohsuke Kawaguchi kkawagu...@cloudbees.com wrote: We could put both current and the new in the same repo, and call the new one perforce plugin 2.0. […] We can have alpha/beta releases of 2.0 in parallel to updates to 1.x releases. People on the beta update center will get this 2.0 beta versions. When 2.0 is in feature parity, we can have the official 2.0 release. Is there some advantage of this over my suggestion—to add the new SCM implementation to a single release line of the same plugin, marking the original one as somehow deprecated in labels help text? There are clearly some disadvantages: · Users will not know they even have the option of using a new system unless they enable the experimental UC, drastically reducing the number of people who will try it. · Users would not be able to try out the new implementation on one or two experimental jobs while leaving more important jobs in a stable configuration. They would have to update the plugin to 2.0 beta n, restart Jenkins, then update the configuration of all of their jobs not yet handled by automatic data migration, and hope there are no critical regressions. · Similarly, users deciding that 2.0 is not yet ready would have to deal with downgrading to 1.0 via Plugin Manager (*), restarting Jenkins, then probably reconfiguring all Perforce-based jobs even if they did not use any 2.x features (since 1.x would presumably not be able to read any 2.x data). In a nutshell, I am suggesting to move linearly forward, rather than using branches, making the parallel options available via two SCMDescriptor’s in independent package hierarchies. (*) Which is not straightforward if they went from 1.x to 2.0 beta 1 to 2.0 beta 2, since PM would offer to downgrade only to 2.0 beta 1. They would have to manually download 1.x and install it via the Advanced tab. -- 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/d/optout.
Re: New plugin repository hosting and Jira module request (TestFairy)
I had some issues joining this group (tried first to join using a distribution list as email address) Now I have joined with my personal email address. Shell I provide something else in order to obtain the plugin hosting? Thanks, Ciprian On Wednesday, April 16, 2014 2:08:21 PM UTC+3, Ciprian Mester wrote: Hi, We would like repository hosting for a new plugin: TestFairy It performs Android apk uploads to https://www.testfairy.com/ as a post build step. *Jenkins Plugin Name:* TestFairy *Current Location:* private github repository containing multiple projects. We would like to commit only plugin code to the new repo. *Our GitHub Users:* cmester, icotora, io3pg *Our JenkinsCI User:* jenkins3pillar Thank you! Ciprian -- 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/d/optout.
Re: New plugin Perforce
On Thu, Apr 17, 2014 at 5:20 AM, pallen pal...@perforce.com wrote: Perforce would like to release a new re-architected Jenkins plugin called 'p4'. Is this intended to be a full replacement for the existing jenkinsci/perforce-plugin? If so, it should reuse that repository and artifactId/shortName. If not, then the relationship between the plugins needs to be clarified. -- 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/d/optout.
Re: New plugin Perforce
The existing 'perforce' plugin is used by many of our customers and I was concerned that effectively replacing it with the new plugin may upset some users. Whilst the new plugin provides all the basic SCM functions, it is not yet as feature rich. We plan to add features over the next few months and are keen to involve the community as much as possible. We would obviously like to use the 'Perforce' name space; perhaps there is a way to branch (fork) the old codebase into a legacy area? Paul On 17 Apr 2014, at 16:31, Jesse Glick jgl...@cloudbees.com wrote: On Thu, Apr 17, 2014 at 5:20 AM, pallen pal...@perforce.com wrote: Perforce would like to release a new re-architected Jenkins plugin called 'p4'. Is this intended to be a full replacement for the existing jenkinsci/perforce-plugin? If so, it should reuse that repository and artifactId/shortName. If not, then the relationship between the plugins needs to be clarified. -- 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/d/optout. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Perforce Software. Finally, the recipient should check this email and any attachments for the presence of viruses. Perforce Software accepts no liability for any damage caused by any virus transmitted by this email. Perforce Software UK Ltd is registered in England and Wales as company no. 3816019 at the following address: West Forest Gate, Wellington Road, Wokingham, RG40 2AT, UK -- 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/d/optout.
Re: New plugin Perforce
On Thu, Apr 17, 2014 at 11:51 AM, Paul Allen pal...@perforce.com wrote: Whilst the new plugin provides all the basic SCM functions, it is not yet as feature rich. We plan to add features […] […] perhaps there is a way to branch (fork) the old codebase into a legacy area? A bit more work, but arguably better for users, would be to include the new refactored implementation inside the existing plugin (in trunk versions). For a time, users of the plugin would see two SCM options—Perforce (v1) and Perforce (v2)—with somewhat different configuration UIs and functionality. They could experiment with switching to v2, or go back for a while, on a project-by-project basis. You could even decide that v1 configurations restricted to a certain set of commonly used features would be safe to automatically upgrade (i.e., readResolve) to a v2 configuration. Eventually the v1 implementation could be dropped, or rather exist only as a class with a readResolve method. This is of course assuming that the current maintainer(s) of perforce-plugin are aware of your effort and on board with it. -- 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/d/optout.
Re: New plugin Perforce
I have been discussing the plugin for sometime over email. I'll CC Rob and the others... Paul On 17 Apr 2014, at 16:59, Jesse Glick jgl...@cloudbees.com wrote: On Thu, Apr 17, 2014 at 11:51 AM, Paul Allen pal...@perforce.com wrote: Whilst the new plugin provides all the basic SCM functions, it is not yet as feature rich. We plan to add features [...] [...] perhaps there is a way to branch (fork) the old codebase into a legacy area? A bit more work, but arguably better for users, would be to include the new refactored implementation inside the existing plugin (in trunk versions). For a time, users of the plugin would see two SCM options--Perforce (v1) and Perforce (v2)--with somewhat different configuration UIs and functionality. They could experiment with switching to v2, or go back for a while, on a project-by-project basis. You could even decide that v1 configurations restricted to a certain set of commonly used features would be safe to automatically upgrade (i.e., readResolve) to a v2 configuration. Eventually the v1 implementation could be dropped, or rather exist only as a class with a readResolve method. This is of course assuming that the current maintainer(s) of perforce-plugin are aware of your effort and on board with it. -- 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/d/optout. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Perforce Software. Finally, the recipient should check this email and any attachments for the presence of viruses. Perforce Software accepts no liability for any damage caused by any virus transmitted by this email. Perforce Software UK Ltd is registered in England and Wales as company no. 3816019 at the following address: West Forest Gate, Wellington Road, Wokingham, RG40 2AT, UK -- 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/d/optout.
Re: New plugin Perforce
I thought it was decided that refactoring the old plugin was the better way to go? It's less of an impact on users, and preserves all of the required functionality. If not, then just make a new repo, I guess... On Thursday, 17 April 2014 10:52:20 UTC-6, pallen wrote: I have been discussing the plugin for sometime over email. I'll CC Rob and the others... Paul On 17 Apr 2014, at 16:59, Jesse Glick jgl...@cloudbees.com javascript: wrote: On Thu, Apr 17, 2014 at 11:51 AM, Paul Allen pal...@perforce.comjavascript: wrote: Whilst the new plugin provides all the basic SCM functions, it is not yet as feature rich. We plan to add features […] […] perhaps there is a way to branch (fork) the old codebase into a legacy area? A bit more work, but arguably better for users, would be to include the new refactored implementation inside the existing plugin (in trunk versions). For a time, users of the plugin would see two SCM options—Perforce (v1) and Perforce (v2)—with somewhat different configuration UIs and functionality. They could experiment with switching to v2, or go back for a while, on a project-by-project basis. You could even decide that v1 configurations restricted to a certain set of commonly used features would be safe to automatically upgrade (i.e., readResolve) to a v2 configuration. Eventually the v1 implementation could be dropped, or rather exist only as a class with a readResolve method. This is of course assuming that the current maintainer(s) of perforce-plugin are aware of your effort and on board with it. -- 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/d/optout. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Perforce Software. Finally, the recipient should check this email and any attachments for the presence of viruses. Perforce Software accepts no liability for any damage caused by any virus transmitted by this email. Perforce Software UK Ltd is registered in England and Wales as company no. 3816019 at the following address: West Forest Gate, Wellington Road, Wokingham, RG40 2AT, UK -- 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/d/optout.
New plugin repository hosting and Jira module request (TestFairy)
Hi, We would like repository hosting for a new plugin: TestFairy It performs Android apk uploads to https://www.testfairy.com/ as a post build step. *Jenkins Plugin Name:* TestFairy *Current Location:* private github repository containing multiple projects. We would like to commit only plugin code to the new repo. *Our GitHub Users:* cmester, icotora, io3pg *Our JenkinsCI User:* jenkins3pillar Thank you! Ciprian -- 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/d/optout.
Re: New Plugin Repository Request (artifactory-polling-plugin)
Hi Larry, I would be interested in creating a similar tool for gradle, perhaps I will get in touch with the XTrigger developers and talk to them about developing something. The gradle tooling API will support this in the next release I believe so this may be achievable soon. The XTrigger framework seems like it would fit this sort of plugin well. Cheers Nathan On Tuesday, 8 April 2014 15:44:11 UTC-6, Larry Shatzer, Jr. wrote: Nathan, Is it possible you could contribute to one of those solutions to add the features you need? Such as a better persistence of the data, or add support for reading a gradle file for the maven or ivy one, since aren't the artifacts still reachable by a maven coordinate? We just want to try and avoid having TOO many plugins that do the SAME thing, or VERY similar. Having lots of plugins is good, just don't want to dilute existing ones. -- Larry On Tue, Apr 8, 2014 at 2:04 PM, Nathan Gutzmann nathang...@gmail.comjavascript: wrote: Hi Larry, Unfortunately the Maven Dependency Update trigger and the IvyTrigger Plugin will not work for us as we use gradle instead of Maven or Ivy. I also looked at the URL trigger from the XTtrigger plugin, however this plugin does not persist any state outside of RAM. As a result, any changes that are made if Jenkins is rebooted will not be picked up. This is unfortunately not an option for us. Additionally the artifactory polling plugin allows us to filter the job trigger based on a dynamic dependency version. Thanks for pointing out the other options but unfortunately none of them are a good fit for our problem. Believe me, I would have used a pre-build solution if a satisfactory one existed. Cheers Nathan On Tuesday, 8 April 2014 12:19:54 UTC-6, Larry Shatzer, Jr. wrote: How is that different than https://wiki.jenkins-ci. org/display/JENKINS/Maven+Dependency+Update+trigger (or say https://wiki.jenkins-ci.org/display/JENKINS/IvyTrigger+Plugin or other ones listed here: https://wiki.jenkins-ci.org/display/JENKINS/XTrigger+ Plugin) On Tue, Apr 8, 2014 at 11:23 AM, Nathan Gutzmann nathang...@gmail.comwrote: Hi Jenkins Developers, I've created a new plugin which is an implementation of an SCM style plugin. It can be used to poll Artifactory (open source or pro) for new versions of dependencies and trigger jobs when these dependencies are updated. My github username is ngutzmann. Please call the repo artifactory-polling-plugin if possible. Cheers Nathan -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
Re: New Plugin
bump. Should we use Jira to track which new repo requests for Plugins were addressed? It's hard to know if a request will be taken by someone. Regards, Fabio. On Monday, April 7, 2014 9:47:49 PM UTC+10, Fabio Douek wrote: Hi, I developed a new Jenkins plugin, and I was wondering if I can get commit access and a new repo created in jenkinsci. Once the repo is created, if I run a maven release, would that be immediately be available in the site update, or there is a periodic job to build/publish the plugins from the GIT repo? Plugin name: myst-plugin Git Hub ID: 7000332 Git Hub User ID: fdouek-rxr https://github.com/rubiconred/myst-jenkins-plugin https://wiki.jenkins-ci.org/display/JENKINS/MyST+Plugin Thanks, Fabio. -- 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/d/optout.
Re: New Plugin
It's not a bad idea, we'd need to create a new component and assign to someone who was willing to be consistent on it. Perhaps a plugin review committee that reviews submissions of new plugins. It could turn out to be too much though. I'll try and fork your repo this morning to get you up and running. slide On Wed, Apr 9, 2014 at 5:56 AM, Fabio Douek fabio.do...@rubiconred.comwrote: bump. Should we use Jira to track which new repo requests for Plugins were addressed? It's hard to know if a request will be taken by someone. Regards, Fabio. On Monday, April 7, 2014 9:47:49 PM UTC+10, Fabio Douek wrote: Hi, I developed a new Jenkins plugin, and I was wondering if I can get commit access and a new repo created in jenkinsci. Once the repo is created, if I run a maven release, would that be immediately be available in the site update, or there is a periodic job to build/publish the plugins from the GIT repo? Plugin name: myst-plugin Git Hub ID: 7000332 Git Hub User ID: fdouek-rxr https://github.com/rubiconred/myst-jenkins-plugin https://wiki.jenkins-ci.org/display/JENKINS/MyST+Plugin Thanks, Fabio. -- 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/d/optout. -- Website: http://earl-of-code.com -- 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/d/optout.
Re: New Plugin
Welcome aboard 15:10 +Slide-O-Mix jenkins-admin: fork rubiconred/myst-jenkins-plugin as myst-plugin 15:10 @jenkins-admin Forking myst-jenkins-plugin 15:10 @jenkins-admin *Created https://github.com/jenkinsci/myst-plugin https://github.com/jenkinsci/myst-plugin* 15:11 +Slide-O-Mix jenkins-admin: create myst in the issue tracker for fdouek 15:11 @jenkins-admin *Adding a new subcomponent myst to the bug tracker, owned by fdouek* 15:11 @jenkins-admin New component created 15:12 +Slide-O-Mix jenkins-admin: make fdouek-rxr a committer of myst-plugin 15:12 @jenkins-admin *Added fdouek-rxr as a GitHub committer for repository myst-plugin* On Mon, Apr 7, 2014 at 4:47 AM, Fabio Douek fabio.do...@rubiconred.comwrote: Hi, I developed a new Jenkins plugin, and I was wondering if I can get commit access and a new repo created in jenkinsci. Once the repo is created, if I run a maven release, would that be immediately be available in the site update, or there is a periodic job to build/publish the plugins from the GIT repo? Plugin name: myst-plugin Git Hub ID: 7000332 Git Hub User ID: fdouek-rxr https://github.com/rubiconred/myst-jenkins-plugin https://wiki.jenkins-ci.org/display/JENKINS/MyST+Plugin Thanks, Fabio. -- 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/d/optout. -- Website: http://earl-of-code.com -- 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/d/optout.
Re: New Plugin
Thanks Slide, I just checked at https://jenkins.ci.cloudbees.com/job/plugins/ , and I couldn't find the Jenkins job to build the plugin. Is this required, or can I just release it from the command line? Regards, Fabio. On Thursday, April 10, 2014 1:13:19 AM UTC+10, slide wrote: Welcome aboard 15:10 +Slide-O-Mix jenkins-admin: fork rubiconred/myst-jenkins-plugin as myst-plugin 15:10 @jenkins-admin Forking myst-jenkins-plugin 15:10 @jenkins-admin *Created https://github.com/jenkinsci/myst-plugin https://github.com/jenkinsci/myst-plugin* 15:11 +Slide-O-Mix jenkins-admin: create myst in the issue tracker for fdouek 15:11 @jenkins-admin *Adding a new subcomponent myst to the bug tracker, owned by fdouek* 15:11 @jenkins-admin New component created 15:12 +Slide-O-Mix jenkins-admin: make fdouek-rxr a committer of myst-plugin 15:12 @jenkins-admin *Added fdouek-rxr as a GitHub committer for repository myst-plugin* On Mon, Apr 7, 2014 at 4:47 AM, Fabio Douek fabio...@rubiconred.comjavascript: wrote: Hi, I developed a new Jenkins plugin, and I was wondering if I can get commit access and a new repo created in jenkinsci. Once the repo is created, if I run a maven release, would that be immediately be available in the site update, or there is a periodic job to build/publish the plugins from the GIT repo? Plugin name: myst-plugin Git Hub ID: 7000332 Git Hub User ID: fdouek-rxr https://github.com/rubiconred/myst-jenkins-plugin https://wiki.jenkins-ci.org/display/JENKINS/MyST+Plugin Thanks, Fabio. -- 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/d/optout. -- Website: http://earl-of-code.com -- 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/d/optout.
Re: New Plugin
No, it's not required to have anything on cloudbees for a release. I don't have access to add the plugin to the CI, it's something I am not sure how to get done actually. You can mvn release:prepare release:perform to your heart's content. slide On Wed, Apr 9, 2014 at 10:00 AM, Fabio Douek fabio.do...@rubiconred.comwrote: Thanks Slide, I just checked at https://jenkins.ci.cloudbees.com/job/plugins/ , and I couldn't find the Jenkins job to build the plugin. Is this required, or can I just release it from the command line? Regards, Fabio. On Thursday, April 10, 2014 1:13:19 AM UTC+10, slide wrote: Welcome aboard 15:10 +Slide-O-Mix jenkins-admin: fork rubiconred/myst-jenkins-plugin as myst-plugin 15:10 @jenkins-admin Forking myst-jenkins-plugin 15:10 @jenkins-admin *Created https://github.com/jenkinsci/myst-plugin https://github.com/jenkinsci/myst-plugin* 15:11 +Slide-O-Mix jenkins-admin: create myst in the issue tracker for fdouek 15:11 @jenkins-admin *Adding a new subcomponent myst to the bug tracker, owned by fdouek* 15:11 @jenkins-admin New component created 15:12 +Slide-O-Mix jenkins-admin: make fdouek-rxr a committer of myst-plugin 15:12 @jenkins-admin *Added fdouek-rxr as a GitHub committer for repository myst-plugin* On Mon, Apr 7, 2014 at 4:47 AM, Fabio Douek fabio...@rubiconred.comwrote: Hi, I developed a new Jenkins plugin, and I was wondering if I can get commit access and a new repo created in jenkinsci. Once the repo is created, if I run a maven release, would that be immediately be available in the site update, or there is a periodic job to build/publish the plugins from the GIT repo? Plugin name: myst-plugin Git Hub ID: 7000332 Git Hub User ID: fdouek-rxr https://github.com/rubiconred/myst-jenkins-plugin https://wiki.jenkins-ci.org/display/JENKINS/MyST+Plugin Thanks, Fabio. -- 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/d/optout. -- Website: http://earl-of-code.com -- 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/d/optout. -- Website: http://earl-of-code.com -- 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/d/optout.
Re: New Plugin
On 09.04.2014, at 19:33, Slide slide.o@gmail.com wrote: I don't have access to add the plugin to the CI, it's something I am not sure how to get done actually Happens automatically ever few hours via https://ci.jenkins-ci.org/job/infra_backend_jenkins_ci_cloudbess_com_filler/ (I doubt the job gets much traffic, given the typo in the name.) -- 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/d/optout.
Re: New Plugin
On Wed, Apr 9, 2014 at 11:04 AM, Daniel Beck m...@beckweb.net wrote: On 09.04.2014, at 19:33, Slide slide.o@gmail.com wrote: I don't have access to add the plugin to the CI, it's something I am not sure how to get done actually Happens automatically ever few hours via https://ci.jenkins-ci.org/job/infra_backend_jenkins_ci_cloudbess_com_filler/ (I doubt the job gets much traffic, given the typo in the name.) That's fantastic, I had no idea it was there. Thanks for the info. Perhaps someone could update the name :-) -- Website: http://earl-of-code.com -- 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/d/optout.
Re: New Plugin 'Artifact Promotion' / hosting request
Sorry for the delay: https://github.com/jenkinsci/artifact-promotion-plugin Welcome aboard! Ulli Am 08.04.2014 um 09:51 schrieb Halil-Cem Gürsoy hcguer...@gmail.com: *bump* Did I missed something in my initial request? -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: New Plugin 'Artifact Promotion' / hosting request
*bump* Did I missed something in my initial request? -- 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/d/optout.
New Plugin Repository Request (artifactory-polling-plugin)
Hi Jenkins Developers, I've created a new plugin which is an implementation of an SCM style plugin. It can be used to poll Artifactory (open source or pro) for new versions of dependencies and trigger jobs when these dependencies are updated. My github username is ngutzmann. Please call the repo artifactory-polling-plugin if possible. Cheers Nathan -- 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/d/optout.
Re: New Plugin Repository Request (artifactory-polling-plugin)
How is that different than https://wiki.jenkins-ci.org/display/JENKINS/Maven+Dependency+Update+trigger(or say https://wiki.jenkins-ci.org/display/JENKINS/IvyTrigger+Plugin or other ones listed here: https://wiki.jenkins-ci.org/display/JENKINS/XTrigger+Plugin) On Tue, Apr 8, 2014 at 11:23 AM, Nathan Gutzmann nathangutzm...@gmail.comwrote: Hi Jenkins Developers, I've created a new plugin which is an implementation of an SCM style plugin. It can be used to poll Artifactory (open source or pro) for new versions of dependencies and trigger jobs when these dependencies are updated. My github username is ngutzmann. Please call the repo artifactory-polling-plugin if possible. Cheers Nathan -- 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/d/optout. -- 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/d/optout.
Re: New Plugin Repository Request (artifactory-polling-plugin)
Hi Larry, Unfortunately the Maven Dependency Update trigger and the IvyTrigger Plugin will not work for us as we use gradle instead of Maven or Ivy. I also looked at the URL trigger from the XTtrigger plugin, however this plugin does not persist any state outside of RAM. As a result, any changes that are made if Jenkins is rebooted will not be picked up. This is unfortunately not an option for us. Additionally the artifactory polling plugin allows us to filter the job trigger based on a dynamic dependency version. Thanks for pointing out the other options but unfortunately none of them are a good fit for our problem. Believe me, I would have used a pre-build solution if a satisfactory one existed. Cheers Nathan On Tuesday, 8 April 2014 12:19:54 UTC-6, Larry Shatzer, Jr. wrote: How is that different than https://wiki.jenkins-ci.org/display/JENKINS/Maven+Dependency+Update+trigger(or say https://wiki.jenkins-ci.org/display/JENKINS/IvyTrigger+Plugin or other ones listed here: https://wiki.jenkins-ci.org/display/JENKINS/XTrigger+Plugin) On Tue, Apr 8, 2014 at 11:23 AM, Nathan Gutzmann nathang...@gmail.comjavascript: wrote: Hi Jenkins Developers, I've created a new plugin which is an implementation of an SCM style plugin. It can be used to poll Artifactory (open source or pro) for new versions of dependencies and trigger jobs when these dependencies are updated. My github username is ngutzmann. Please call the repo artifactory-polling-plugin if possible. Cheers Nathan -- 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/d/optout. -- 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/d/optout.
Re: New Plugin Repository Request (artifactory-polling-plugin)
Nathan, Is it possible you could contribute to one of those solutions to add the features you need? Such as a better persistence of the data, or add support for reading a gradle file for the maven or ivy one, since aren't the artifacts still reachable by a maven coordinate? We just want to try and avoid having TOO many plugins that do the SAME thing, or VERY similar. Having lots of plugins is good, just don't want to dilute existing ones. -- Larry On Tue, Apr 8, 2014 at 2:04 PM, Nathan Gutzmann nathangutzm...@gmail.comwrote: Hi Larry, Unfortunately the Maven Dependency Update trigger and the IvyTrigger Plugin will not work for us as we use gradle instead of Maven or Ivy. I also looked at the URL trigger from the XTtrigger plugin, however this plugin does not persist any state outside of RAM. As a result, any changes that are made if Jenkins is rebooted will not be picked up. This is unfortunately not an option for us. Additionally the artifactory polling plugin allows us to filter the job trigger based on a dynamic dependency version. Thanks for pointing out the other options but unfortunately none of them are a good fit for our problem. Believe me, I would have used a pre-build solution if a satisfactory one existed. Cheers Nathan On Tuesday, 8 April 2014 12:19:54 UTC-6, Larry Shatzer, Jr. wrote: How is that different than https://wiki.jenkins-ci. org/display/JENKINS/Maven+Dependency+Update+trigger (or say https://wiki.jenkins-ci.org/display/JENKINS/IvyTrigger+Plugin or other ones listed here: https://wiki.jenkins-ci.org/display/JENKINS/XTrigger+ Plugin) On Tue, Apr 8, 2014 at 11:23 AM, Nathan Gutzmann nathang...@gmail.comwrote: Hi Jenkins Developers, I've created a new plugin which is an implementation of an SCM style plugin. It can be used to poll Artifactory (open source or pro) for new versions of dependencies and trigger jobs when these dependencies are updated. My github username is ngutzmann. Please call the repo artifactory-polling-plugin if possible. Cheers Nathan -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
Re: New plugin for Play!Framework
I think it makes sense to contact the other author before releasing a different plugin. We can still decide what to do after that... Am 04.04.2014 um 15:13 schrieb Rafael Ribeiro Rezende rafaelrez...@gmail.com: Hello all, I'm about to finish a plugin to build Play!Framework projects from Jenkins. There is already an available implementation from Takafumi Ikeda that hasn't been maintained since some 3 years ago. Play!Framework changed a lot since then and Jenkins have grown up a lot as well. In summary, the plugin doesn't seem to work anymore (at least I didn't manage to make it work without repairing some source code). It uses some deprecated methods as well. https://github.com/jenkinsci/play-plugin Then, I decided to create a plugin from scratch. It's simpler in terms of implementation, but with a better interface (imo) and structure. I plan to contact the Play!Framework community soon to get some better use cases and see how I could improve it a bit more... Anyway, my question here is: should I release it to jenkins as a new plugin or should I contact the play-plugin developer and see if I could overwrite it? From one hand, it's a complete new code, new project, which could characterise it as a new plugin. On the other hand, it provides more o less the functionality of the existing plugin, which is no longer supported and, afaik, broken. (I can be wrong here, ok?) So, the next step depends pretty much on the policy of the Jenkins community regarding plugin release. Cheers, Rafael -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
New Plugin
Hi, I developed a new Jenkins plugin, and I was wondering if I can get commit access and a new repo created in jenkinsci. Once the repo is created, if I run a maven release, would that be immediately be available in the site update, or there is a periodic job to build/publish the plugins from the GIT repo? Plugin name: myst-plugin Git Hub ID: 7000332 Git Hub User ID: fdouek-rxr https://github.com/rubiconred/myst-jenkins-plugin https://wiki.jenkins-ci.org/display/JENKINS/MyST+Plugin Thanks, Fabio. -- 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/d/optout.
Re: New plugin (poll-mailbox-trigger) Hosting and Repository Request
Hi Slide, First of all, thank for setting that up! What credentials should I be using to connect to repo.jenkins-ci.org? (I've tried resetting the password for nickg, nickgrealy, and my email nickgrealy at gmail dot com, no luck, credentials not found) Kind regards, Nick Grealy On Monday, 7 April 2014 15:24:45 UTC+10, slide wrote: I forked the repo into the jenkinsci org and added you as a committer [1]. I also created a JIRA component [2] with you as the default assignee. Welcome aboard! slide 1 - https://github.com/jenkinsci/poll-mailbox-trigger-plugin 2 - https://issues.jenkins-ci.org/secure/IssueNavigator.jspa?mode=hidereset=truejqlQuery=project+%3D+JENKINS+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%29+AND+component+%3D+poll-mailbox-trigger On Fri, Apr 4, 2014 at 4:45 PM, Nick Grealy nickg...@gmail.comjavascript: wrote: Hi, I'm creating a Jenkins plugin, poll a mailbox and trigger jobs based on new matching emails. Could you please create hosting and fork my github jenkins plugin? *Jenkins Plugin Name:* poll-mailbox-trigger *Current Location:* https://github.com/nickgrealy/poll-mailbox-trigger *My GitHub User:* nickgrealy *My JenkinsCI User:* nickg Thank you! Nick -- 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/d/optout. -- Website: http://earl-of-code.com -- 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/d/optout.
Re: New plugin (poll-mailbox-trigger) Hosting and Repository Request
Hi Slide, Nevermind, I worked it out. Thank you! Kind regards, Nick On Tuesday, 8 April 2014 00:14:43 UTC+10, Nick Grealy wrote: Hi Slide, First of all, thank for setting that up! What credentials should I be using to connect to repo.jenkins-ci.org? (I've tried resetting the password for nickg, nickgrealy, and my email nickgrealy at gmail dot com, no luck, credentials not found) Kind regards, Nick Grealy On Monday, 7 April 2014 15:24:45 UTC+10, slide wrote: I forked the repo into the jenkinsci org and added you as a committer [1]. I also created a JIRA component [2] with you as the default assignee. Welcome aboard! slide 1 - https://github.com/jenkinsci/poll-mailbox-trigger-plugin 2 - https://issues.jenkins-ci.org/secure/IssueNavigator.jspa?mode=hidereset=truejqlQuery=project+%3D+JENKINS+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%29+AND+component+%3D+poll-mailbox-trigger On Fri, Apr 4, 2014 at 4:45 PM, Nick Grealy nickg...@gmail.com wrote: Hi, I'm creating a Jenkins plugin, poll a mailbox and trigger jobs based on new matching emails. Could you please create hosting and fork my github jenkins plugin? *Jenkins Plugin Name:* poll-mailbox-trigger *Current Location:* https://github.com/nickgrealy/poll-mailbox-trigger *My GitHub User:* nickgrealy *My JenkinsCI User:* nickg Thank you! Nick -- 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/d/optout. -- Website: http://earl-of-code.com -- 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/d/optout.
Re: New plugin (poll-mailbox-trigger) Hosting and Repository Request
bump On Saturday, 5 April 2014 10:45:55 UTC+11, Nick Grealy wrote: Hi, I'm creating a Jenkins plugin, poll a mailbox and trigger jobs based on new matching emails. Could you please create hosting and fork my github jenkins plugin? *Jenkins Plugin Name:* poll-mailbox-trigger *Current Location:* https://github.com/nickgrealy/poll-mailbox-trigger *My GitHub User:* nickgrealy *My JenkinsCI User:* nickg Thank you! Nick -- 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/d/optout.
Re: New plugin (poll-mailbox-trigger) Hosting and Repository Request
I forked the repo into the jenkinsci org and added you as a committer [1]. I also created a JIRA component [2] with you as the default assignee. Welcome aboard! slide 1 - https://github.com/jenkinsci/poll-mailbox-trigger-plugin 2 - https://issues.jenkins-ci.org/secure/IssueNavigator.jspa?mode=hidereset=truejqlQuery=project+%3D+JENKINS+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%29+AND+component+%3D+poll-mailbox-trigger On Fri, Apr 4, 2014 at 4:45 PM, Nick Grealy nickgre...@gmail.com wrote: Hi, I'm creating a Jenkins plugin, poll a mailbox and trigger jobs based on new matching emails. Could you please create hosting and fork my github jenkins plugin? *Jenkins Plugin Name:* poll-mailbox-trigger *Current Location:* https://github.com/nickgrealy/poll-mailbox-trigger *My GitHub User:* nickgrealy *My JenkinsCI User:* nickg Thank you! Nick -- 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/d/optout. -- Website: http://earl-of-code.com -- 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/d/optout.
New plugin for Play!Framework
Hello all, I'm about to finish a plugin to build Play!Framework projects from Jenkins. There is already an available implementation from Takafumi Ikeda that hasn't been maintained since some 3 years ago. Play!Framework changed a lot since then and Jenkins have grown up a lot as well. In summary, the plugin doesn't seem to work anymore (at least I didn't manage to make it work without repairing some source code). It uses some deprecated methods as well. https://github.com/jenkinsci/play-plugin Then, I decided to create a plugin from scratch. It's simpler in terms of implementation, but with a better interface (imo) and structure. I plan to contact the Play!Framework community soon to get some better use cases and see how I could improve it a bit more... Anyway, my question here is: *should I release it to jenkins as a new plugin or should I contact the play-plugin developer and see if I could overwrite it?* From one hand, it's a complete new code, new project, which could characterise it as a new plugin. On the other hand, it provides more o less the functionality of the existing plugin, which is no longer supported and, afaik, broken. (I can be wrong here, ok?) So, the next step depends pretty much on the policy of the Jenkins community regarding plugin release. Cheers, Rafael -- 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/d/optout.
New Plugin 'Artifact Promotion' / hosting request
Hi Folks, I've started developing a new plugin called 'Artifact Promotion'. The main purpose of this plugin is to give the ability to move an artifact from a 'staging' (maven style) repository into a 'release' repository. I write this because 'artifact promotion' is not supported in the open source editions of the main repository servers like Sonatype Nexus or Artifactory. Only the 'pro' versions support something like 'artifact staging'. In the first step I'll support Nexus but will make it open to enable further support for other servers like Artifactory or Archiva. Now my coordinates: github user: hcguersoy github ID: 778536 Kind regards Halil -- 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/d/optout.
Re: new plugin (stash branch parameters plugin)
Created https://github.com/jenkinsci/stash-branch-parameters-plugin Which SCMs are supported? Welcome aboard! Ulli Am 24.03.2014 um 22:14 schrieb Erw Oldenkamp oldenkamper...@gmail.com: Hello, I'd like to create a new plugin to build branches and tags via a parameter. GitHub username: eernie GitHub repo: https://github.com/Eernie/StashBranchParametersPlugin Plugin name: Stash Branch Parameters plugin Please help grant the commit access. Thanks, Eernie -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: new plugin (stash branch parameters plugin)
Stash is a git server. So my intentions are git only Op dinsdag 25 maart 2014 11:37:57 UTC+1 schreef Ullrich Hafner: Created https://github.com/jenkinsci/stash-branch-parameters-plugin Which SCMs are supported? Welcome aboard! Ulli Am 24.03.2014 um 22:14 schrieb Erw Oldenkamp oldenka...@gmail.comjavascript: : Hello, I'd like to create a new plugin to build branches and tags via a parameter. GitHub username: eernie GitHub repo: https://github.com/Eernie/StashBranchParametersPlugin Plugin name: Stash Branch Parameters plugin Please help grant the commit access. Thanks, Eernie -- 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/d/optout. -- 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/d/optout.
new plugin (stash branch parameters plugin)
Hello, I'd like to create a new plugin to build branches and tags via a parameter. GitHub username: eernie GitHub repo: https://github.com/Eernie/StashBranchParametersPlugin Plugin name: Stash Branch Parameters plugin Please help grant the commit access. Thanks, Eernie -- 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/d/optout.
Re: New Plugin Hosting Request (Scoverage)
Created: https://github.com/jenkinsci/scoverage-plugin Welcome aboard! Ulli Am 21.03.2014 um 07:54 schrieb Shanbin Wang shanbin.w...@gmail.com: Hello, I'd like to create a new plugin to publish Scala code coverage trend graph based on scoverage results. GitHub username: shanbin GitHub repo: https://github.com/shanbin/scoverage-plugin Plugin name: Scoverage Plugin Please help grant the commit access. Thanks, Shanbin -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: New Plugin Hosting Request (Scoverage)
Thank you Ulli! On Friday, March 21, 2014 2:54:15 PM UTC+8, Shanbin Wang wrote: Hello, I'd like to create a new plugin to publish Scala code coverage trend graph based on scoverage results. GitHub username: shanbin GitHub repo: https://github.com/shanbin/scoverage-plugin Plugin name: Scoverage Plugin Please help grant the commit access. Thanks, Shanbin -- 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/d/optout.
Re: New Plugin Hosting Request (Scoverage)
Thank you Ulli! On Saturday, March 22, 2014 6:35:30 PM UTC+8, Ullrich Hafner wrote: Created: https://github.com/jenkinsci/scoverage-plugin Welcome aboard! Ulli Am 21.03.2014 um 07:54 schrieb Shanbin Wang shanbi...@gmail.comjavascript: : Hello, I'd like to create a new plugin to publish Scala code coverage trend graph based on scoverage results. GitHub username: shanbin GitHub repo: https://github.com/shanbin/scoverage-plugin Plugin name: Scoverage Plugin Please help grant the commit access. Thanks, Shanbin -- 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/d/optout. -- 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/d/optout.
New Plugin Hosting Request (Scoverage)
Hello, I'd like to create a new plugin to publish Scala code coverage trend graph based on scoverage results. GitHub username: shanbin GitHub repo: https://github.com/shanbin/scoverage-plugin Plugin name: Scoverage Plugin Please help grant the commit access. Thanks, Shanbin -- 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/d/optout.
Re: Publish a new plugin named MultiChannelPacker..
I think the name should be changed to something more expessing what the plugin really does Domi On 12.03.2014, at 02:16, Jango Chu jango...@gmail.com wrote: Ok,I have translated it into English. Jango -- View this message in context: http://jenkins-ci.361315.n4.nabble.com/Publish-a-new-plugin-named-MultiChannelPacker-tp4693950p4694093.html Sent from the Jenkins dev mailing list archive at Nabble.com. -- 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/d/optout. -- 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/d/optout.
Re: Need access to jenkins repo for new plugin
Here is the repo for the plugin : https://github.com/smarth-madan/periodic-projects-scanner-balancer This plugin's role is to analyze and balance the build load resulted by periodic jobs. Kindly grant me access for committing it. thanks Smarth On Wednesday, March 19, 2014 2:26:40 PM UTC-7, Smarth Madan wrote: Hi, I need commit access to https://github.com/jenkinsci to create a new repo for a plugin. Github ID: smarth-madanPlugin name: periodic-projects-scanner-balancer Thanks Smarth Madan -- 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/d/optout.
Re: Need access to jenkins repo for new plugin
Created https://github.com/jenkinsci/periodic-jobs-balancer-plugin Welcome aboard! Ulli Am 20.03.2014 um 19:21 schrieb Smarth Madan madan.sma...@gmail.com: Here is the repo for the plugin : https://github.com/smarth-madan/periodic-projects-scanner-balancer This plugin's role is to analyze and balance the build load resulted by periodic jobs. Kindly grant me access for committing it. thanks Smarth On Wednesday, March 19, 2014 2:26:40 PM UTC-7, Smarth Madan wrote: Hi, I need commit access to https://github.com/jenkinsci to create a new repo for a plugin. Github ID: smarth-madanPlugin name: periodic-projects-scanner-balancer Thanks Smarth Madan -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: need commit access in github to publish new plugin
How about enriching that plugin with your new plugin feature and merge the two? Le 18 mars 2014 14:14, Gurpreet Singh rgssi...@gmail.com a écrit : As it loads thing dynamically so i think dynamic-extended-choice- parameter-pluginhttps://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fextended-choice-parameter-pluginsa=Dsntz=1usg=AFQjCNETR3VXDR_Y_THT71WhWuEzlAL0rg is appropriate name for this. On Tuesday, March 18, 2014 5:57:27 PM UTC+5:30, Ullrich Hafner wrote: What would be an appropriate name of the plug-in? We already have https://github.com/jenkinsci/extended-choice-parameter-plugin Ulli Am 18.03.2014 um 10:53 schrieb Gurpreet Singh rgss...@gmail.com: Difference is that in extended plugin it will load content from properties file at start up of the page but in my dynamic extended plugin it load content of the properties files based on your selection in bind field. Means you have to setup two field in your jenkins jobs one is linked to another based on your selection on primary list content of the secondary will gets changed on the fly through ajax call in dynamic extended plugin. Also my plugin has svn support means it will list out all branches/tags/trunk in svn url that you have setup in jenkins job based on your selection in primary field which has trunk/tags/branches. On Tuesday, March 18, 2014 2:13:18 PM UTC+5:30, Ullrich Hafner wrote: Yes, but what is the difference? The other plugin also loads property files? If it is not the same then the name should be different. Or can it be integrated into the other plugin? Am 18.03.2014 um 09:22 schrieb Gurpreet Singh rgss...@gmail.com: Hi Ullrich My plugin will load dynamically properties file based on your selection and also it will load dynamically svn list of branches/tags based on your selection. On Thursday, March 13, 2014 8:50:07 PM UTC+5:30, Gurpreet Singh wrote: Dear jenkins devs, I would like to publish our new Dynamic Extended choice plugin Plugin for Jenkins. Find below the details requested: Plugin Name: Dynamic Extended choice plugin GITHUB username: rgssingh Thanks in advance, RGS Singh -- 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/d/optout. -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
need commit access in github to publish new plugin : composer-security-checker-plugin
Dear jenkins devs, I would like to publish our new Plugin for Jenkins. Find below the details requested: Plugin Name: composer-security-checker-plugin GITHUB username: easylo GITHUB link: https://github.com/easylo/composer-security-checker-plugin Description: this plugin is for projects using composer in dependency management. it uses Security Advisories Checker API (https://security.sensiolabs.org) to check the file composer.lock Thanks in advance, -- 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/d/optout.
Re: need commit access in github to publish new plugin : composer-security-checker-plugin
https://github.com/jenkinsci/composer-security-checker-plugin 2014-03-19 9:46 GMT+01:00 Laurent RICHARD eas...@gmail.com: Dear jenkins devs, I would like to publish our new Plugin for Jenkins. Find below the details requested: Plugin Name: composer-security-checker-plugin GITHUB username: easylo GITHUB link: https://github.com/easylo/composer-security-checker-plugin Description: this plugin is for projects using composer in dependency management. it uses Security Advisories Checker API (https://security.sensiolabs.org) to check the file composer.lock Thanks in advance, -- 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/d/optout. -- 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/d/optout.
Re: need commit access in github to publish new plugin
Hi Baptiste As i already mentioned above that my plugin loads thing dynamically based on binded field so both have different set of functionality we can't merge them. Please create placeholder for it so that i can start committing it. Name should be dynamic-extended-choice-parameter plugin. On Wednesday, March 19, 2014 1:08:40 PM UTC+5:30, Baptiste Mathus wrote: How about enriching that plugin with your new plugin feature and merge the two? Le 18 mars 2014 14:14, Gurpreet Singh rgss...@gmail.com javascript: a écrit : As it loads thing dynamically so i think dynamic-extended-choice- parameter-pluginhttps://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fextended-choice-parameter-pluginsa=Dsntz=1usg=AFQjCNETR3VXDR_Y_THT71WhWuEzlAL0rg is appropriate name for this. On Tuesday, March 18, 2014 5:57:27 PM UTC+5:30, Ullrich Hafner wrote: What would be an appropriate name of the plug-in? We already have https://github.com/jenkinsci/extended-choice-parameter-plugin Ulli Am 18.03.2014 um 10:53 schrieb Gurpreet Singh rgss...@gmail.com: Difference is that in extended plugin it will load content from properties file at start up of the page but in my dynamic extended plugin it load content of the properties files based on your selection in bind field. Means you have to setup two field in your jenkins jobs one is linked to another based on your selection on primary list content of the secondary will gets changed on the fly through ajax call in dynamic extended plugin. Also my plugin has svn support means it will list out all branches/tags/trunk in svn url that you have setup in jenkins job based on your selection in primary field which has trunk/tags/branches. On Tuesday, March 18, 2014 2:13:18 PM UTC+5:30, Ullrich Hafner wrote: Yes, but what is the difference? The other plugin also loads property files? If it is not the same then the name should be different. Or can it be integrated into the other plugin? Am 18.03.2014 um 09:22 schrieb Gurpreet Singh rgss...@gmail.com: Hi Ullrich My plugin will load dynamically properties file based on your selection and also it will load dynamically svn list of branches/tags based on your selection. On Thursday, March 13, 2014 8:50:07 PM UTC+5:30, Gurpreet Singh wrote: Dear jenkins devs, I would like to publish our new Dynamic Extended choice plugin Plugin for Jenkins. Find below the details requested: Plugin Name: Dynamic Extended choice plugin GITHUB username: rgssingh Thanks in advance, RGS Singh -- 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/d/optout. -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
Re: need commit access in github to publish new plugin : composer-security-checker-plugin
thanks. can i have right for commit ? on https://github.com/jenkinsci/composer-security-checker-plugin thanks thanks On Wednesday, March 19, 2014 10:01:59 AM UTC+1, nicolas de loof wrote: https://github.com/jenkinsci/composer-security-checker-plugin 2014-03-19 9:46 GMT+01:00 Laurent RICHARD eas...@gmail.com javascript: : Dear jenkins devs, I would like to publish our new Plugin for Jenkins. Find below the details requested: Plugin Name: composer-security-checker-plugin GITHUB username: easylo GITHUB link: https://github.com/easylo/composer-security-checker-plugin Description: this plugin is for projects using composer in dependency management. it uses Security Advisories Checker API ( https://security.sensiolabs.org) to check the file composer.lock Thanks in advance, -- 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/d/optout. -- 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/d/optout.
Re: need commit access in github to publish new plugin : composer-security-checker-plugin
Done. Am 19.03.2014 um 11:45 schrieb Laurent RICHARD eas...@gmail.com: thanks. can i have right for commit ? on https://github.com/jenkinsci/composer-security-checker-plugin thanks thanks On Wednesday, March 19, 2014 10:01:59 AM UTC+1, nicolas de loof wrote: https://github.com/jenkinsci/composer-security-checker-plugin 2014-03-19 9:46 GMT+01:00 Laurent RICHARD eas...@gmail.com: Dear jenkins devs, I would like to publish our new Plugin for Jenkins. Find below the details requested: Plugin Name: composer-security-checker-plugin GITHUB username: easylo GITHUB link: https://github.com/easylo/composer-security-checker-plugin Description: this plugin is for projects using composer in dependency management. it uses Security Advisories Checker API (https://security.sensiolabs.org) to check the file composer.lock Thanks in advance, -- 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/d/optout. -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: need commit access in github to publish new plugin
https://github.com/jenkinsci/dynamic-extended-choice-parameter-plugin Welcome aboard! Ulli Am 19.03.2014 um 10:57 schrieb Gurpreet Singh rgssi...@gmail.com: Hi Baptiste As i already mentioned above that my plugin loads thing dynamically based on binded field so both have different set of functionality we can't merge them. Please create placeholder for it so that i can start committing it. Name should be dynamic-extended-choice-parameter plugin. On Wednesday, March 19, 2014 1:08:40 PM UTC+5:30, Baptiste Mathus wrote: How about enriching that plugin with your new plugin feature and merge the two? Le 18 mars 2014 14:14, Gurpreet Singh rgss...@gmail.com a écrit : As it loads thing dynamically so i think dynamic-extended-choice-parameter-plugin is appropriate name for this. On Tuesday, March 18, 2014 5:57:27 PM UTC+5:30, Ullrich Hafner wrote: What would be an appropriate name of the plug-in? We already have https://github.com/jenkinsci/extended-choice-parameter-plugin Ulli Am 18.03.2014 um 10:53 schrieb Gurpreet Singh rgss...@gmail.com: Difference is that in extended plugin it will load content from properties file at start up of the page but in my dynamic extended plugin it load content of the properties files based on your selection in bind field. Means you have to setup two field in your jenkins jobs one is linked to another based on your selection on primary list content of the secondary will gets changed on the fly through ajax call in dynamic extended plugin. Also my plugin has svn support means it will list out all branches/tags/trunk in svn url that you have setup in jenkins job based on your selection in primary field which has trunk/tags/branches. On Tuesday, March 18, 2014 2:13:18 PM UTC+5:30, Ullrich Hafner wrote: Yes, but what is the difference? The other plugin also loads property files? If it is not the same then the name should be different. Or can it be integrated into the other plugin? Am 18.03.2014 um 09:22 schrieb Gurpreet Singh rgss...@gmail.com: Hi Ullrich My plugin will load dynamically properties file based on your selection and also it will load dynamically svn list of branches/tags based on your selection. On Thursday, March 13, 2014 8:50:07 PM UTC+5:30, Gurpreet Singh wrote: Dear jenkins devs, I would like to publish our new Dynamic Extended choice plugin Plugin for Jenkins. Find below the details requested: Plugin Name: Dynamic Extended choice plugin GITHUB username: rgssingh Thanks in advance, RGS Singh -- 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/d/optout. -- 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/d/optout. -- 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/d/optout. -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: need commit access in github to publish new plugin : composer-security-checker-plugin
thanks On Wednesday, March 19, 2014 12:17:05 PM UTC+1, Ullrich Hafner wrote: Done. Am 19.03.2014 um 11:45 schrieb Laurent RICHARD eas...@gmail.comjavascript: : thanks. can i have right for commit ? on https://github.com/jenkinsci/composer-security-checker-plugin thanks thanks On Wednesday, March 19, 2014 10:01:59 AM UTC+1, nicolas de loof wrote: https://github.com/jenkinsci/composer-security-checker-plugin 2014-03-19 9:46 GMT+01:00 Laurent RICHARD eas...@gmail.com: Dear jenkins devs, I would like to publish our new Plugin for Jenkins. Find below the details requested: Plugin Name: composer-security-checker-plugin GITHUB username: easylo GITHUB link: https://github.com/easylo/composer-security-checker-plugin Description: this plugin is for projects using composer in dependency management. it uses Security Advisories Checker API ( https://security.sensiolabs.org) to check the file composer.lock Thanks in advance, -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
Re: need commit access in github to publish new plugin
Thanks Ulli. On Wednesday, March 19, 2014 4:48:30 PM UTC+5:30, Ullrich Hafner wrote: https://github.com/jenkinsci/dynamic-extended-choice-parameter-plugin Welcome aboard! Ulli Am 19.03.2014 um 10:57 schrieb Gurpreet Singh rgss...@gmail.comjavascript: : Hi Baptiste As i already mentioned above that my plugin loads thing dynamically based on binded field so both have different set of functionality we can't merge them. Please create placeholder for it so that i can start committing it. Name should be dynamic-extended-choice-parameter plugin. On Wednesday, March 19, 2014 1:08:40 PM UTC+5:30, Baptiste Mathus wrote: How about enriching that plugin with your new plugin feature and merge the two? Le 18 mars 2014 14:14, Gurpreet Singh rgss...@gmail.com a écrit : As it loads thing dynamically so i think dynamic-extended-choice- parameter-pluginhttps://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fextended-choice-parameter-pluginsa=Dsntz=1usg=AFQjCNETR3VXDR_Y_THT71WhWuEzlAL0rg is appropriate name for this. On Tuesday, March 18, 2014 5:57:27 PM UTC+5:30, Ullrich Hafner wrote: What would be an appropriate name of the plug-in? We already have https://github.com/jenkinsci/extended-choice-parameter-plugin Ulli Am 18.03.2014 um 10:53 schrieb Gurpreet Singh rgss...@gmail.com: Difference is that in extended plugin it will load content from properties file at start up of the page but in my dynamic extended plugin it load content of the properties files based on your selection in bind field. Means you have to setup two field in your jenkins jobs one is linked to another based on your selection on primary list content of the secondary will gets changed on the fly through ajax call in dynamic extended plugin. Also my plugin has svn support means it will list out all branches/tags/trunk in svn url that you have setup in jenkins job based on your selection in primary field which has trunk/tags/branches. On Tuesday, March 18, 2014 2:13:18 PM UTC+5:30, Ullrich Hafner wrote: Yes, but what is the difference? The other plugin also loads property files? If it is not the same then the name should be different. Or can it be integrated into the other plugin? Am 18.03.2014 um 09:22 schrieb Gurpreet Singh rgss...@gmail.com: Hi Ullrich My plugin will load dynamically properties file based on your selection and also it will load dynamically svn list of branches/tags based on your selection. On Thursday, March 13, 2014 8:50:07 PM UTC+5:30, Gurpreet Singh wrote: Dear jenkins devs, I would like to publish our new Dynamic Extended choice plugin Plugin for Jenkins. Find below the details requested: Plugin Name: Dynamic Extended choice plugin GITHUB username: rgssingh Thanks in advance, RGS Singh -- 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/d/optout. -- 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/d/optout. -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
Need access to jenkins repo for new plugin
Hi, I need commit access to https://github.com/jenkinsci to create a new repo for a plugin. Github ID: smarth-madanPlugin name: periodic-projects-scanner-balancer Thanks Smarth Madan -- 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/d/optout.
Re: need commit access in github to publish new plugin
Hi Ullrich My plugin will load dynamically properties file based on your selection and also it will load dynamically svn list of branches/tags based on your selection. On Thursday, March 13, 2014 8:50:07 PM UTC+5:30, Gurpreet Singh wrote: Dear jenkins devs, I would like to publish our new Dynamic Extended choice plugin Plugin for Jenkins. Find below the details requested: Plugin Name: Dynamic Extended choice plugin GITHUB username: rgssingh Thanks in advance, RGS Singh -- 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/d/optout.
Re: need commit access in github to publish new plugin
Yes, but what is the difference? The other plugin also loads property files? If it is not the same then the name should be different. Or can it be integrated into the other plugin? Am 18.03.2014 um 09:22 schrieb Gurpreet Singh rgssi...@gmail.com: Hi Ullrich My plugin will load dynamically properties file based on your selection and also it will load dynamically svn list of branches/tags based on your selection. On Thursday, March 13, 2014 8:50:07 PM UTC+5:30, Gurpreet Singh wrote: Dear jenkins devs, I would like to publish our new Dynamic Extended choice plugin Plugin for Jenkins. Find below the details requested: Plugin Name: Dynamic Extended choice plugin GITHUB username: rgssingh Thanks in advance, RGS Singh -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: need commit access in github to publish new plugin
What would be an appropriate name of the plug-in? We already have https://github.com/jenkinsci/extended-choice-parameter-plugin Ulli Am 18.03.2014 um 10:53 schrieb Gurpreet Singh rgssi...@gmail.com: Difference is that in extended plugin it will load content from properties file at start up of the page but in my dynamic extended plugin it load content of the properties files based on your selection in bind field. Means you have to setup two field in your jenkins jobs one is linked to another based on your selection on primary list content of the secondary will gets changed on the fly through ajax call in dynamic extended plugin. Also my plugin has svn support means it will list out all branches/tags/trunk in svn url that you have setup in jenkins job based on your selection in primary field which has trunk/tags/branches. On Tuesday, March 18, 2014 2:13:18 PM UTC+5:30, Ullrich Hafner wrote: Yes, but what is the difference? The other plugin also loads property files? If it is not the same then the name should be different. Or can it be integrated into the other plugin? Am 18.03.2014 um 09:22 schrieb Gurpreet Singh rgss...@gmail.com: Hi Ullrich My plugin will load dynamically properties file based on your selection and also it will load dynamically svn list of branches/tags based on your selection. On Thursday, March 13, 2014 8:50:07 PM UTC+5:30, Gurpreet Singh wrote: Dear jenkins devs, I would like to publish our new Dynamic Extended choice plugin Plugin for Jenkins. Find below the details requested: Plugin Name: Dynamic Extended choice plugin GITHUB username: rgssingh Thanks in advance, RGS Singh -- 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/d/optout. -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: need commit access in github to publish new plugin
As it loads thing dynamically so i think dynamic- extended-choice-parameter-pluginhttps://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fextended-choice-parameter-pluginsa=Dsntz=1usg=AFQjCNETR3VXDR_Y_THT71WhWuEzlAL0rg is appropriate name for this. On Tuesday, March 18, 2014 5:57:27 PM UTC+5:30, Ullrich Hafner wrote: What would be an appropriate name of the plug-in? We already have https://github.com/jenkinsci/extended-choice-parameter-plugin Ulli Am 18.03.2014 um 10:53 schrieb Gurpreet Singh rgss...@gmail.comjavascript: : Difference is that in extended plugin it will load content from properties file at start up of the page but in my dynamic extended plugin it load content of the properties files based on your selection in bind field. Means you have to setup two field in your jenkins jobs one is linked to another based on your selection on primary list content of the secondary will gets changed on the fly through ajax call in dynamic extended plugin. Also my plugin has svn support means it will list out all branches/tags/trunk in svn url that you have setup in jenkins job based on your selection in primary field which has trunk/tags/branches. On Tuesday, March 18, 2014 2:13:18 PM UTC+5:30, Ullrich Hafner wrote: Yes, but what is the difference? The other plugin also loads property files? If it is not the same then the name should be different. Or can it be integrated into the other plugin? Am 18.03.2014 um 09:22 schrieb Gurpreet Singh rgss...@gmail.com: Hi Ullrich My plugin will load dynamically properties file based on your selection and also it will load dynamically svn list of branches/tags based on your selection. On Thursday, March 13, 2014 8:50:07 PM UTC+5:30, Gurpreet Singh wrote: Dear jenkins devs, I would like to publish our new Dynamic Extended choice plugin Plugin for Jenkins. Find below the details requested: Plugin Name: Dynamic Extended choice plugin GITHUB username: rgssingh Thanks in advance, RGS Singh -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
Re: New plugin hosting request
Created https://github.com/jenkinsci/semantic-versioning-plugin Welcome aboard! Ulli Am 15.03.2014 um 23:30 schrieb ciroque.dr...@gmail.com: Hi, I would like to add a new plugin to the repo. As per the instructions: The plugin name is: SemanticVersioning My Github id is: ciroque Existing Githib repo: https://github.com/ciroque/SemanticVersioning The plugin parses both SBT-based and POM-based build definition files and populates a build variable for use in later build steps. Additionally, the version is written to a file in the artifact directory. The second part of the plugin creates a new column that shows the version for the most-recent successful build. The version is generated based on the value in the build definition file with the Jenkins build number subbed in for the, well, build number. SNAPSHOT builds are supported as well. I searched around and the only thing I found that was remotely close is this project which has only skeleton files in place, no functionality. In the short term I intend on adding parsing support for build.sbt files. I am most definitely open to feature requests and pull requests for enhancing the functionality. Best, Steve Wagner -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
New plugin hosting request
Hi, I would like to add a new plugin to the repo. As per the instructions: The plugin name is: SemanticVersioning My Github id is: ciroque Existing Githib repo: https://github.com/ciroque/SemanticVersioning The plugin parses both SBT-based and POM-based build definition files and populates a build variable for use in later build steps. Additionally, the version is written to a file in the artifact directory. The second part of the plugin creates a new column that shows the version for the most-recent successful build. The version is generated based on the value in the build definition file with the Jenkins build number subbed in for the, well, build number. SNAPSHOT builds are supported as well. I searched around and the only thing I found that was remotely close is this project which has only skeleton files in place, no functionality. In the short term I intend on adding parsing support for build.sbt files. I am most definitely open to feature requests and pull requests for enhancing the functionality. Best, Steve Wagner -- 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/d/optout.
new plugin etiquette
I have a couple plugins that I plan to open source and release in the coming week or so. I believe I have commit access to github.com/jenkinsci, but wanted to check on new plugin etiquette prior to just creating a new repo for each? Just want to make sure I'm not abusing my (limited) power. thanks, -M -- Matthew Moore SWE Google -- 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/d/optout.
Commit access to publish new plugin Keivox KMAP Plugin
Dear jenkins devs, We would like to publish our new Keivox KMAP Plugin for Jenkins. Find below the details requested: Plugin Name: 'Keivox KMAP Plugin' GITHUB username: adminkeivox GITHUB ID: #6859679https://www.assembla.com/spaces/kmap_platform/tickets/6859679 Thanks in advance, Rubén Garzón -- 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/d/optout.
need commit access in github to publish new plugin
Dear jenkins devs, I would like to publish our new Dynamic Extended choice plugin Plugin for Jenkins. Find below the details requested: Plugin Name: Dynamic Extended choice plugin GITHUB username: rgssingh Thanks in advance, RGS Singh -- 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/d/optout.
Re: Commit access to publish new plugin Keivox KMAP Plugin
New github repository created at https://github.com/jenkinsci/kmap-plugin Welcome aboard! Ulli Am 13.03.2014 um 12:28 schrieb keivox...@gmail.com: Dear jenkins devs, We would like to publish our new Keivox KMAP Plugin for Jenkins. Find below the details requested: Plugin Name: 'Keivox KMAP Plugin' GITHUB username: adminkeivox GITHUB ID: #6859679 Thanks in advance, Rubén Garzón -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: need commit access in github to publish new plugin
What is the difference to https://wiki.jenkins-ci.org/display/JENKINS/Extended+Choice+Parameter+plugin ? Am 13.03.2014 um 16:20 schrieb Gurpreet Singh rgssi...@gmail.com: Dear jenkins devs, I would like to publish our new Dynamic Extended choice plugin Plugin for Jenkins. Find below the details requested: Plugin Name: Dynamic Extended choice plugin GITHUB username: rgssingh Thanks in advance, RGS Singh -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Publish a new plugin named MultiChannelPacker..
Hi, I'm Jango Chu,and my GitHub ID is ljchu. I just joined the development team of jenkins. And I created a new but userful plugin named MultiChannelPacker. The repository is https://github.com/ljchu/MultiChannelPacker;https://github.com/ljchu/MultiChannelPacker . And it works well on our jenkins in my company . So,what should I do next, can I publish it to jenkins-ci? Yours, Jango Chu. 2014-3-11 -- 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/d/optout.
Publish a new plugin named MultiChannelPacker..
Hi, I'm Jango Chu,and my GitHub ID is ljchu. I just joined the development team of jenkins. And I created a new but userful plugin named MultiChannelPacker. The repository is https://github.com/ljchu/MultiChannelPacker;https://github.com/ljchu/MultiChannelPacker . And it works well on our jenkins in my company . So,what should I do next, can I publish it to jenkins-ci? Yours, Jango Chu. 2014-3-11 -- 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/d/optout.
Re: Publish a new plugin named MultiChannelPacker..
It would help if you could add README and localization in English, otherwise others will not see what your plug-in is all about… Ulli Am 11.03.2014 um 14:48 schrieb jango...@gmail.com: Hi, I'm Jango Chu,and my GitHub ID is ljchu. I just joined the development team of jenkins. And I created a new but userful plugin named MultiChannelPacker. The repository is https://github.com/ljchu/MultiChannelPacker;. And it works well on our jenkins in my company . So,what should I do next, can I publish it to jenkins-ci? Yours, Jango Chu. 2014-3-11 -- 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/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Publish a new plugin named MultiChannelPacker..
what is the plugin all about? Domi On 11.03.2014, at 14:46, jango...@gmail.com wrote: Hi, I'm Jango Chu,and my GitHub ID is ljchu. I just joined the development team of jenkins. And I created a new but userful plugin named MultiChannelPacker. The repository is https://github.com/ljchu/MultiChannelPacker;. And it works well on our jenkins in my company . So,what should I do next, can I publish it to jenkins-ci? Yours, Jango Chu. 2014-3-11 -- 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/d/optout. -- 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/d/optout.
Re: wipe-workspace-plugin - New plugin that adds a trigger that will wipe and (re)build a job nightly.
Out of curiousity- did you ever release this? This would still be a very useful trigger to have. If you haven't released it, what status is the code in... could I implement it myself? -- 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: wipe-workspace-plugin - New plugin that adds a trigger that will wipe and (re)build a job nightly.
I don't think this has ever been implemented, but If you like, just give it a go and try to integrate the https://wiki.jenkins-ci.org/display/JENKINS/Run+Condition+Plugin To get the most flexible solution possible. when done, just send a pull request to get some feedback on the solution. regards Domi On 17.02.2014, at 14:36, Paul Becotte pjbeco...@gmail.com wrote: Out of curiousity- did you ever release this? This would still be a very useful trigger to have. If you haven't released it, what status is the code in... could I implement it myself? -- 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: wipe-workspace-plugin - New plugin that adds a trigger that will wipe and (re)build a job nightly.
Hi Paul. We have been using this plugin for over a year now without problems. It is pretty simple. If there is interest I wouldn't mind releasing it. Best Regards Bjarke Freund-Hansen On Feb 17, 2014 2:36 PM, Paul Becotte pjbeco...@gmail.com wrote: Out of curiousity- did you ever release this? This would still be a very useful trigger to have. If you haven't released it, what status is the code in... could I implement it myself? -- You received this message because you are subscribed to a topic in the Google Groups Jenkins Developers group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/mcokSBUhv-4/unsubscribe. To unsubscribe from this group and all its topics, 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.
