Push access on PowerShell Plugin
Hi, Would it be possible to get push access to this repository? We've been updating the powershell plugin internally to support more advanced powershell features and would love to share what we've done with the community. However, the last pull request for the repository has not been addressed, leading us to believe that this repository is not actively managed. Repository name : https://github.com/jenkinsci/powershell-plugin https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fpowershell-pluginsa=Dsntz=1usg=AFQjCNE73Qi-2qYbdvomeIQ9syTW09Nq7A User ID : precisiondev Thanks, Kyle -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/74f3c3a2-0567-411c-824f-8e705e889488%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Plugins hosted in svn
On Wed, Apr 22, 2015 at 9:16 AM, Robert Sandell rsand...@cloudbees.com wrote: when the bridge was setup it was done so that when new content started to turn up on the github repo that was not in svn the svn - github replication would stop. Right, but there have been cases where commits were made after that point in svn (so forked), and surely there are many cases where the plugin maintainer simply forgot to close the svn dir. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1_aHjj-XngG%2BjOnEmRP8m1i88UMOr4Fa-%3D%3DEHxt78-AA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Request for Jelly Tag library (custom) support : custom tag library not working after restarting Jenkins
A first start could be to study the Folder Plugin https://github.com/jenkinsci/cloudbees-folder-plugin /B On Wed, Apr 22, 2015 at 3:30 PM, vinodhini.vi...@gmail.com wrote: Thank you for your reply. May I know how could I learn this - details of how Jenkins loads and save items ? Is there any Flowchart or Workflow of Jenkins(how internal classes and jellies are connected and loaded) available ? I am really interested in this and also, I would like to contribute plugins to Jenkins. Regards Vinodhini On Wednesday, April 22, 2015 at 4:33:55 PM UTC+5:30, Jesse Glick wrote: On Wed, Apr 22, 2015 at 4:14 AM, vinodhi...@gmail.com wrote: While debugging, at AbstractItem.java:324, I got to see that the parent was null (after Jenkins restart). I am not sure what is wrong and what I am missing. Your SpecialMainProject or its children is somehow to blame, not the Jelly views. Most likely your mistake was persisting its children in the `children` field. This cannot work. Creating a new project type is a serious endeavour; there are a lot of subtle considerations, and you have to understand the details of how Jenkins loads and save items. I would not attempt it unless you are pretty experienced with plugin development. It is usually not something you want to do even then; generally you want to tack behavior on to an existing project type. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bee94117-6f20-4f2d-bd95-cf947379952b%40googlegroups.com https://groups.google.com/d/msgid/jenkinsci-dev/bee94117-6f20-4f2d-bd95-cf947379952b%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Robert Sandell *Software Engineer* *CloudBees Inc.* -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS38hES17cbvQj1YAUkanjsoE_jt-27z%3DgmS1qu3PRkXeQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Plugins hosted in svn
IIRC when the bridge was setup it was done so that when new content started to turn up on the github repo that was not in svn the svn - github replication would stop. /B On Wed, Apr 22, 2015 at 2:59 PM, Jesse Glick jgl...@cloudbees.com wrote: There are still a few plugins hosted in the Jenkins Subversion repository. I am not sure if active changes are being made there. Confusingly, when github.com/jenkinsci was created, we also mirrored those subdirectories as Git repositories. Naturally people have since then submitted GitHub PRs and in some cases pushed to the Git repo while the Subversion repo was active, meaning the plugin is effectively forked. This is a freaking mess. I think we should simply abandon the Subversion repo, meaning creating a new commit that deletes everything, and then removing write access, and request plugin authors to use GitHub. If they insist on using Subversion (and not via the bridge to Git), they can use some other hosting site, but the plugin should not be considered “hosted on jenkins-ci.org”. Ideally some final check would be done for outstanding changes in svn that did not make it into Git for whatever reason. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0j2rsHcDmj1X%3DgBFo%2Bb0tKFkFF5DG7B45yyXor%2BYe5vg%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- Robert Sandell *Software Engineer* *CloudBees Inc.* -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2jhpemKJKCg%2BT35EmQDWmMjCx%3Du5F4W2zm%3DfG92MWXYA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Jenkins UX
If the collapsed/minimized form of the build step config was made pluggable (ex a collapsed.jelly next to config.jelly) the the readability of the overview could maybe be improved, for example a read only view of the first two lines of the execute shell step, the git url for the scm, the include path of the unit test collection etc. Or would that have a risk of cluttering too much? Perhaps could be mitigated with good style guides/default css? /B On Wed, Apr 22, 2015 at 12:54 PM, Jesse Glick jgl...@cloudbees.com wrote: On Tue, Apr 21, 2015 at 12:24 PM, Balder VC li...@redlab.be wrote: Perhaps it would be good to ask feedback from users on de user list, if you didn't already, I would assume they have a slightly different view then developers of Jenkins. On Tue, Apr 21, 2015 at 4:43 PM, Gus Reiber grei...@cloudbees.com wrote: I have not posted to the de list, but I am eager to get quantity of feedback. Can you give me the URL to that list? I have to confess I am not familiar with it. @Gus reread, he said the users list. https://groups.google.com/forum/#!forum/jenkinsci-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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3zkaB3MiGf3sUVUCR7FvLqJ6X6p6v0HBfoNhtOZKTJyA%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- Robert Sandell *Software Engineer* *CloudBees Inc.* -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS1U80cE5wWHhWEFYLDndEFCqeaDASWn96R3E%3Dy1Cq-yhA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Request for Jelly Tag library (custom) support : custom tag library not working after restarting Jenkins
Thank you for your reply. May I know how could I learn this - details of how Jenkins loads and save items ? Is there any Flowchart or Workflow of Jenkins(how internal classes and jellies are connected and loaded) available ? I am really interested in this and also, I would like to contribute plugins to Jenkins. Regards Vinodhini On Wednesday, April 22, 2015 at 4:33:55 PM UTC+5:30, Jesse Glick wrote: On Wed, Apr 22, 2015 at 4:14 AM, vinodhi...@gmail.com javascript: wrote: While debugging, at AbstractItem.java:324, I got to see that the parent was null (after Jenkins restart). I am not sure what is wrong and what I am missing. Your SpecialMainProject or its children is somehow to blame, not the Jelly views. Most likely your mistake was persisting its children in the `children` field. This cannot work. Creating a new project type is a serious endeavour; there are a lot of subtle considerations, and you have to understand the details of how Jenkins loads and save items. I would not attempt it unless you are pretty experienced with plugin development. It is usually not something you want to do even then; generally you want to tack behavior on to an existing project type. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bee94117-6f20-4f2d-bd95-cf947379952b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Getting java exceptions while running my job from Jenkins server
Hi I am getting following exception while building my job. What may be the problem ? http://pastebin.com/14C8ff6c -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/301f3f87-6840-43ac-8b91-a535e6badf54%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What will the next LTS be (was Re: Next LTS is 1.596)
On 22.04.2015, at 11:48, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Where was the discussion on this? See http://echelog.com/logs/browse/jenkins/1422313200 starting at: [20:35:54] ogondza kohsuke: I noticed we forgot to pick new LTS, so if you have a minute... -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/C34E2506-A52C-4D7F-BC68-C73A888D1292%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
Re: What will the next LTS be (was Re: Next LTS is 1.596)
I failed to put in on agenda once again. Sorry about that. On Wed, 22 Apr 2015 13:36:29 +0200, Jesse Glick jgl...@cloudbees.com wrote: I have complained about this to Kohsuke privately but perhaps others are affected too: it would be really helpful if the upcoming LTS baseline were decided (*) well in advance, ... This idea was coined when we discussed last LTS policy update and there was no consensus. I am opened to give it a try as the only change it requires is the date the discussion happens and LTS.next is announced. If some of the concerns proves to be valid we can switch back rather easily. -- oliver -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/op.xxiex9ctsbfict%40localhost.localdomain. For more options, visit https://groups.google.com/d/optout.
Re: Plugins hosted in svn
Hi, Can there be a mass release of plugin POM updates to redirect to git? There is the infra_plugin_changes_report [1] that should update Plugin report page[2], but upload to Wiki is failing (for over a year now). It may be an easy change to generate another list showing plugins with SVN as SCM source. Jan [1] https://ci.jenkins-ci.org/job/infra_plugin_changes_report/ [2] https://wiki.jenkins-ci.org/display/JENKINS/Unreleased+Plugin+Changes On Apr 22, 2015, at 16:35, Richard Bywater wrote: Just to throw something out there... I've never used it so perhaps its not fit for purpose, but given that Github supposedly supports people accessing the repositories via SVN, wouldn't an idea be to make sure that all repositories live on Github and people simply use their choice of SCM tool? Richard. On Thu, 23 Apr 2015 at 08:25 Daniel Beck m...@beckweb.netmailto:m...@beckweb.net wrote: On 22.04.2015, at 14:59, Jesse Glick jgl...@cloudbees.commailto:jgl...@cloudbees.com wrote: I am not sure if active changes are being made there. More than 100 commits this year. Granted, most by just one user, Dimitri Tenenbaum (and some of those because of the recent Artifactory auth problem IIRC), but still. surely there are many cases where the plugin maintainer simply forgot to close the svn dir. Did you actually check the individual plugin folders? More than half of them contain just zero or one file (a README pointing to Github). I cleaned quite a few up in November, replacing sources by a notice that the plugin was moved as seems to be customary when continuing on Github. And most of the rest were plugins untouched for a few years, and I doubt they suddenly became active in large numbers. This is a freaking mess. I don't see it. Sure, if the intention is to reduce the infra we need to maintain, freeing resources for other things, moving plugins to Github could be done. But I don't have the impression that SVN is a drain on resources. And IMO the mess is not nearly as bad as you seem to assume. Of course, what we could do is force all plugins that haven't been updated in either repo since e.g. 2012 (Nicolas' POM mass cleanup) to migrate to Github. I doubt we'll have more than a handful left, and if those ever get picked up again, it'd likely be on Github anyway. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.commailto:jenkinsci-dev%2bunsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5A30E1DB-6B93-4C1E-8474-E1BA8D5743F3%40beckweb.net. 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.commailto:jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMui945%3DeANNAbLLoU3z%3DtjdmGNV5ejMHvf4mDuJbqJqZELUMQ%40mail.gmail.comhttps://groups.google.com/d/msgid/jenkinsci-dev/CAMui945%3DeANNAbLLoU3z%3DtjdmGNV5ejMHvf4mDuJbqJqZELUMQ%40mail.gmail.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. Jan Ruzicka Senior Software Engineer Comtech Mobile Datacom Corporation 20430 Century Blvd, Germantown, MD 20874 Office: 240-686-3300 Fax: 240-686-3301 The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network. NOTICE TO RECIPIENT: This email, including attachments, may contain information which is confidential, proprietary, attorney-client privileged and/or controlled under U.S. export laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email shall create any legal binding agreement between the parties unless expressly stated herein and provided by an authorized representative of Comtech Telecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify us immediately by return email and permanently delete all copies of the original email and any attached documentation from any computer or
Re: Release Active Choices Plug-in (was: Re: New plug-in: Uno Choice Plug-in for dynamic parameters)
Thanks Kanstantsin! If there are no objections maybe someone with karma could clone it, and then I would fix the plug-in name in the code before the 1.0 release :) Bruno From: Kanstantsin Shautsou kanstantsin@gmail.com To: jenkinsci-dev@googlegroups.com Sent: Wednesday, April 22, 2015 3:10 AM Subject: Re: Release Active Choices Plug-in (was: Re: New plug-in: Uno Choice Plug-in for dynamic parameters) imho sounds ok. But not very like “Re-active” for other plugin names. On Apr 21, 2015, at 16:03, 'Bruno P. Kinoshita' via Jenkins Developers jenkinsci-dev@googlegroups.com wrote: Bump again :) What about renaming the plug-in at the repository https://github.com/biouno/uno-choice-plugin To Active Choices Plug-in as Ioannis suggested? The plug-in provides parameter types that can be updated based on other parameter values in the UI. We have already some users downloading the plug-in either manually or from our update center, but we really would like to make it available to all users. Thank you!Bruno From: 'Bruno P. Kinoshita' via Jenkins Developers jenkinsci-dev@googlegroups.com To: jenkinsci-dev@googlegroups.com jenkinsci-dev@googlegroups.com Cc: m...@beckweb.net m...@beckweb.net Sent: Wednesday, April 1, 2015 11:20 AM Subject: Re: New plug-in: Uno Choice Plug-in for dynamic parameters Maybe i already suggested not to use Jenkins word, just XXX plugin Agreed, we can drop the Jenkins prefix. Re-active prefix is not obvious for me... Would you have other suggestions? Unfortunately I'm horrible choosing names :) ThanksBruno From: Kanstantsin Shautsou kanstantsin@gmail.com To: jenkinsci-dev@googlegroups.com Cc: m...@beckweb.net; brunodepau...@yahoo.com.br Sent: Tuesday, March 31, 2015 6:01 PM Subject: Re: New plug-in: Uno Choice Plug-in for dynamic parameters Maybe i already suggested not to use Jenkins word, just XXX plugin Re-active prefix is not obvious for me... On Monday, March 30, 2015 at 11:09:26 PM UTC+3, kinow wrote: Bump anyone? +1 / -1 for Jenkins Active Choices Plug-in? Any other suggestion? CheersBruno From: Ioannis Moutsatsos imout...@gmail.com To: jenkin...@googlegroups.com Cc: m...@beckweb.net Sent: Friday, February 27, 2015 11:47 AM Subject: Re: New plug-in: Uno Choice Plug-in for dynamic parameters What do you all think about naming the plugin 'Active Choices Plugin' . The plugin would then add 3 new parameter types: - Active Choices [aka Uno-Choice Dynamic Choice] - Re-Active Choices [aka Uno-Choice Cascade Dynamic] - Re-Active References [aka Uno-Choice Dynamic Reference] The 'Re-active' prefix perhaps would fit well with the main function of these parameter which is to actively react to changes in other submission form UI parameters. On Thursday, February 19, 2015 at 1:59:19 AM UTC-5, Daniel Beck wrote: On 18.02.2015, at 22:01, Jesse Glick jgl...@cloudbees.com wrote: I would pick a plugin named “Dynamic Parameter” and skip right over “Uno Choice”. There is already 'Dynamic Extended Choice' and 'Dynamic Parameter'. At least with the 'Uno' it has a less generic name and you're not going to confuse it with another plugin all the time. -- 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. To view this discussion on the web visit https://groups.google.com/d/ msgid/jenkinsci-dev/4936cd59- 9505-420d-b37c-1e59e1206357% 40googlegroups.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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b2218c24-4487-447d-b7d9-54623732109f%40googlegroups.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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1906857759.1148400.1427840444347.JavaMail.yahoo%40mail.yahoo.com. For more options, visit https://groups.google.com/d/optout. -- 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/qUBLhE-4ybY/unsubscribe. To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit
Re: plugin hosting request: fedmsg-trigger-plugin
The correct URL to information about Fedmsg is http://www.fedmsg.com/en/latest/ Copy-paste error from my previous plugin hosting request, my apologies.// Michal -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/55388634.40607%40redhat.com. For more options, visit https://groups.google.com/d/optout.
plugin hosting request: fedmsg-trigger-plugin
Hello, I would like to ask for plugin hosting. I am developing Jenkins plugin which allows users to trigger builds via Fedmsg messages [1]. GitHub plugin name: fedmsg-trigger-plugin GitHub ID+jenkins-ci.org ID: msrb GitHub repo: https://github.com/msrb/copr-pluginhttps://github.com/msrb/fedmsg-trigger-plugin Thanks Michal [1]: http://www.fedmsg.com/en/latest/ https://fedorahosted.org/copr/ -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/553883A2.2060602%40redhat.com. For more options, visit https://groups.google.com/d/optout.
Plugins hosted in svn
There are still a few plugins hosted in the Jenkins Subversion repository. I am not sure if active changes are being made there. Confusingly, when github.com/jenkinsci was created, we also mirrored those subdirectories as Git repositories. Naturally people have since then submitted GitHub PRs and in some cases pushed to the Git repo while the Subversion repo was active, meaning the plugin is effectively forked. This is a freaking mess. I think we should simply abandon the Subversion repo, meaning creating a new commit that deletes everything, and then removing write access, and request plugin authors to use GitHub. If they insist on using Subversion (and not via the bridge to Git), they can use some other hosting site, but the plugin should not be considered “hosted on jenkins-ci.org”. Ideally some final check would be done for outstanding changes in svn that did not make it into Git for whatever reason. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0j2rsHcDmj1X%3DgBFo%2Bb0tKFkFF5DG7B45yyXor%2BYe5vg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Jenkins UX
Hello, Thanks a lot for looking into UI improvements. As a Jenkins job config admin, here are some comments about the current job build UI. Radio buttons are not dense enough, it wastes horizontal space and increases the vertical scrolling. For the collapsed and hidden items (e.g. those under Advanced buttons), I would like an indication that something is lurking under there so I am visually reminded to expand them. For the text boxes, please get rid of the need for horizontal scrolling. Big fonts and big icons: density matters. I'd rather see a lot of information at a time with a high density font than have to scroll all the time at a pretty font. Side history panel and upper left corner links: more space for configuration if they are removed when configuring a job. Keep up the good work and thank you again, Martin -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bf33fc37-7f19-4069-ad8c-bf29026a525a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Plugins hosted in svn
On 22.04.2015, at 14:59, Jesse Glick jgl...@cloudbees.com wrote: I am not sure if active changes are being made there. More than 100 commits this year. Granted, most by just one user, Dimitri Tenenbaum (and some of those because of the recent Artifactory auth problem IIRC), but still. surely there are many cases where the plugin maintainer simply forgot to close the svn dir. Did you actually check the individual plugin folders? More than half of them contain just zero or one file (a README pointing to Github). I cleaned quite a few up in November, replacing sources by a notice that the plugin was moved as seems to be customary when continuing on Github. And most of the rest were plugins untouched for a few years, and I doubt they suddenly became active in large numbers. This is a freaking mess. I don't see it. Sure, if the intention is to reduce the infra we need to maintain, freeing resources for other things, moving plugins to Github could be done. But I don't have the impression that SVN is a drain on resources. And IMO the mess is not nearly as bad as you seem to assume. Of course, what we could do is force all plugins that haven't been updated in either repo since e.g. 2012 (Nicolas' POM mass cleanup) to migrate to Github. I doubt we'll have more than a handful left, and if those ever get picked up again, it'd likely be on Github anyway. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5A30E1DB-6B93-4C1E-8474-E1BA8D5743F3%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
Re: What will the next LTS be (was Re: Next LTS is 1.596)
On Wed, Apr 22, 2015 at 3:55 PM, oliver gondža ogon...@gmail.com wrote: If some of the concerns proves to be valid we can switch back rather easily. I do not recall the conversation. Do you remember what the concerns were? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0z%3DCHbHOP1UifTvhJPdw%3DX-U80rQY10W8k4Eq3wkwR9w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Plugins hosted in svn
Just to throw something out there... I've never used it so perhaps its not fit for purpose, but given that Github supposedly supports people accessing the repositories via SVN, wouldn't an idea be to make sure that all repositories live on Github and people simply use their choice of SCM tool? Richard. On Thu, 23 Apr 2015 at 08:25 Daniel Beck m...@beckweb.net wrote: On 22.04.2015, at 14:59, Jesse Glick jgl...@cloudbees.com wrote: I am not sure if active changes are being made there. More than 100 commits this year. Granted, most by just one user, Dimitri Tenenbaum (and some of those because of the recent Artifactory auth problem IIRC), but still. surely there are many cases where the plugin maintainer simply forgot to close the svn dir. Did you actually check the individual plugin folders? More than half of them contain just zero or one file (a README pointing to Github). I cleaned quite a few up in November, replacing sources by a notice that the plugin was moved as seems to be customary when continuing on Github. And most of the rest were plugins untouched for a few years, and I doubt they suddenly became active in large numbers. This is a freaking mess. I don't see it. Sure, if the intention is to reduce the infra we need to maintain, freeing resources for other things, moving plugins to Github could be done. But I don't have the impression that SVN is a drain on resources. And IMO the mess is not nearly as bad as you seem to assume. Of course, what we could do is force all plugins that haven't been updated in either repo since e.g. 2012 (Nicolas' POM mass cleanup) to migrate to Github. I doubt we'll have more than a handful left, and if those ever get picked up again, it'd likely be on Github anyway. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5A30E1DB-6B93-4C1E-8474-E1BA8D5743F3%40beckweb.net . 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMui945%3DeANNAbLLoU3z%3DtjdmGNV5ejMHvf4mDuJbqJqZELUMQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Request for Jelly Tag library (custom) support : custom tag library not working after restarting Jenkins
Hello All, I have a created a special Build Job. Jenkins New job Build Special project Ok. This creates few other child projects as FreeStyleProject. I have a main.jelly file in the src/main/resources/com/myproject/SpecialMainProject . I would like to list down all child projects in the Special Project Page (similar to upstream or downstream list). I created xmlns:local=local namespace using upstream-downstream.jelly file as reference. When I create my special project, I could see all my child projects as below: The problem now is , when I restart Jenkins, all child jobs looks like show below and I get the below exception: *Exception:* Apr 22, 2015 1:24:28 PM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: job.buildStatusUrl in /jenkins/job/Special/. Reason: java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor208.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:74) at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) at org.apache.commons.jelly.expression.ExpressionSupport.evaluateAsString(ExpressionSupport.java:46) at org.apache.commons.jelly.expression.CompositeExpression.evaluateAsString(CompositeExpression.java:256) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.buildAttributes(ReallyStaticTagLibrary.java:111) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:95) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:81) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:124) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:146) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at
What will the next LTS be (was Re: Next LTS is 1.596)
Where was the discussion on this? I couldn't find it anywhere in http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-01-07-19.01.log.html or http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-01-21-19.01.log.html I am asking because I would like to know what the next LTS will be... and my understanding was that it was discussed at the governance meetings and instead the only reference I can see is this thread where it was just announced /me hoping for 1.607+ or 1.610 ideally On 27 January 2015 at 22:02, oliver gondža ogon...@gmail.com wrote: Hi, We have agreed on new LTS baseline version as 1.580 reached its end of life. Users can expect first RC based on 1.596 on 2015-02-04. -- oliver -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/op.xs455pzksbfict%40localhost.localdomain . 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxUYPc1g1yUTBRWGmc44CTZ3xVcmhkdPhr7C9xj5-pwFQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Jenkins UX
On Tue, Apr 21, 2015 at 12:24 PM, Balder VC li...@redlab.be wrote: Perhaps it would be good to ask feedback from users on de user list, if you didn't already, I would assume they have a slightly different view then developers of Jenkins. On Tue, Apr 21, 2015 at 4:43 PM, Gus Reiber grei...@cloudbees.com wrote: I have not posted to the de list, but I am eager to get quantity of feedback. Can you give me the URL to that list? I have to confess I am not familiar with it. @Gus reread, he said the users list. https://groups.google.com/forum/#!forum/jenkinsci-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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3zkaB3MiGf3sUVUCR7FvLqJ6X6p6v0HBfoNhtOZKTJyA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Unit testing a plugin with global configuration properties
On Wed, Apr 22, 2015 at 12:24 AM, andrew.sum...@customs.govt.nz wrote: Any idea why this is not working? Something is wrong with your configuration form. In general if you misuse Jelly controls you will get either crazy layout, or a cryptic JavaScript exception. Try something else until it works, or look to a well-established working plugin for an example to start from. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2pOahgAkvr3yyLCcUCT24VMw2vf9VXStLtmvGXJijYPA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Request for Jelly Tag library (custom) support : custom tag library not working after restarting Jenkins
On Wed, Apr 22, 2015 at 4:14 AM, vinodhini.vi...@gmail.com wrote: While debugging, at AbstractItem.java:324, I got to see that the parent was null (after Jenkins restart). I am not sure what is wrong and what I am missing. Your SpecialMainProject or its children is somehow to blame, not the Jelly views. Most likely your mistake was persisting its children in the `children` field. This cannot work. Creating a new project type is a serious endeavour; there are a lot of subtle considerations, and you have to understand the details of how Jenkins loads and save items. I would not attempt it unless you are pretty experienced with plugin development. It is usually not something you want to do even then; generally you want to tack behavior on to an existing project type. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2V6bw2b_BvxxBn%3DbF_Eoa0gQSxcc0%2BAS%3DAte02u24MwA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: What will the next LTS be (was Re: Next LTS is 1.596)
On Wed, Apr 22, 2015 at 5:48 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Where was the discussion on this? I couldn't find it anywhere in jenkins.2015-01-07-19.01.log.html or jenkins.2015-01-21-19.01.log.html Not sure why you are looking at logs in January! According to https://wiki.jenkins-ci.org/display/JENKINS/LTS+Release+Line the next baseline is picked around the time 1.596.3 is released. The RC was posted on Apr 05, meaning the release should have been on Apr 19/20. Clearly that did not happen; maybe Kohsuke just forgot? Picking a baseline generally happens during a project meeting, which is not for another week, though I suppose it could be done on the dev list as well. /me hoping for 1.607+ or 1.610 ideally /me hoping for 1.607+ definitely, or 1.609+ ideally, and if not 1.610+ then I certainly have some `lts-candidate`s I will push for. I have complained about this to Kohsuke privately but perhaps others are affected too: it would be really helpful if the upcoming LTS baseline were decided (*) well in advance, so that people writing APIs would know when those changes would actually be available for use from plugins with LTS dependencies (as is usually preferred). As it stands, for workflow-plugin I have the master branch on 1.596.x, a branch using APIs from 1.599+ intended for the next LTS, a branch on top of that branch (!) using 1.609+ which may or may not be in the next LTS, and an unrelated branch using 1.607+ which will probably be in the next LTS but I am not sure. I cannot collapse these branches without running the risk that the LTS will be earlier than 1.609 and I will have to revert some of my changes and put them back in a branch. It would be a lot less work, and merge conflicts, if I knew in advance what I was going to get in May, and could plan accordingly. Indeed my core changes could be planned with a schedule in mind, and reviewers could ask for a particularly dangerous-looking PR to be put on hold if a new baseline were imminent. Put another way, the current policy is fine if you think of Jenkins core releases as more or less equivalent, but some more stable than others according to a couple dozen user ratings, so we might as well pick a reasonably recent sunny one so fewer regression fixes need to be backported. It does not work when you think of core as a platform with APIs that plugin authors are awaiting the delivery of. I realize that most plugins use rather old core dependencies and are not much affected, so perhaps mine is a minority complaint. (*) Since we seem to have replaced the RC system with a policy of doing multiple 1.xxx releases in a week if warranted, the decision would be better stated in terms of a date, rather than a version number. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2paJyCam8YCcSn8TZ-vZzdmghLMLBOpcHYjYbbKtr%2Brg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: What will the next LTS be (was Re: Next LTS is 1.596)
On 22 April 2015 at 12:36, Jesse Glick jgl...@cloudbees.com wrote: On Wed, Apr 22, 2015 at 5:48 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Where was the discussion on this? I couldn't find it anywhere in jenkins.2015-01-07-19.01.log.html or jenkins.2015-01-21-19.01.log.html Not sure why you are looking at logs in January! I was trying to find where 1.596 was selected as the LTS line... 1.596 was released in January and On Feb 4th we just have 19:42:19 kohsuke #topic LTS RC status19:42:30 kohsuke #action Kohsuke to put LTS schedules in the calendar19:42:39 ogondza kohsuke: we are ready19:42:46 hgilmore Thank you19:42:49 kohsuke ogondza: yay19:42:58 kohsuke all right, that was easy On Feb 18th, we have: 20:02:14 kohsuke #topic LTS status check20:02:30 ogondza kohsuke: we are ready20:02:47 kohsuke ogondza: yay, nice and sweet On Mar 4th we have: 19:00:32 kohsuke_ #topic LTS RC status check19:00:50 ogondza kohsuke_: ready for RC19:01:08 kohsuke_ I failed once again to push 1.596.1 in time, so my hats off to you ogondza19:01:26 ogondza no problem So by March 4th 1.596 was chosen as the LTS line. The only reference I could see to 1.596 being selected was the mail on 27th of Jan from ogondza which would mean that I should expect to see in the logs during January the discussion of which LTS line to pick... but no sign or sight According to https://wiki.jenkins-ci.org/display/JENKINS/LTS+Release+Line the next baseline is picked around the time 1.596.3 is released. The RC was posted on Apr 05, meaning the release should have been on Apr 19/20. Clearly that did not happen; maybe Kohsuke just forgot? Picking a baseline generally happens during a project meeting, which is not for another week, though I suppose it could be done on the dev list as well. /me hoping for 1.607+ or 1.610 ideally /me hoping for 1.607+ definitely, or 1.609+ ideally, and if not 1.610+ then I certainly have some `lts-candidate`s I will push for. I have complained about this to Kohsuke privately but perhaps others are affected too: it would be really helpful if the upcoming LTS baseline were decided (*) well in advance, so that people writing APIs would know when those changes would actually be available for use from plugins with LTS dependencies (as is usually preferred). As it stands, for workflow-plugin I have the master branch on 1.596.x, a branch using APIs from 1.599+ intended for the next LTS, a branch on top of that branch (!) using 1.609+ which may or may not be in the next LTS, and an unrelated branch using 1.607+ which will probably be in the next LTS but I am not sure. I cannot collapse these branches without running the risk that the LTS will be earlier than 1.609 and I will have to revert some of my changes and put them back in a branch. It would be a lot less work, and merge conflicts, if I knew in advance what I was going to get in May, and could plan accordingly. Indeed my core changes could be planned with a schedule in mind, and reviewers could ask for a particularly dangerous-looking PR to be put on hold if a new baseline were imminent. Put another way, the current policy is fine if you think of Jenkins core releases as more or less equivalent, but some more stable than others according to a couple dozen user ratings, so we might as well pick a reasonably recent sunny one so fewer regression fixes need to be backported. It does not work when you think of core as a platform with APIs that plugin authors are awaiting the delivery of. I realize that most plugins use rather old core dependencies and are not much affected, so perhaps mine is a minority complaint. (*) Since we seem to have replaced the RC system with a policy of doing multiple 1.xxx releases in a week if warranted, the decision would be better stated in terms of a date, rather than a version number. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2paJyCam8YCcSn8TZ-vZzdmghLMLBOpcHYjYbbKtr%2Brg%40mail.gmail.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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMzFJ9MoCmmD%3DgV-6VEUGjD14o-ua7dFy9FoxgYZ%2B%3DT8wQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Groovy template for subject in email-ext plugin
I need help in creating a groovy template for subject in email-ext plugin. I have configured email-ext plugin to send emails on every build failure. I want to check my build log and if it contains text 'abc' then it should set subject to 'ProjectName - failed due to abc' and if it doesn't then to 'ProjectName - failed due to xyz' -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/edf24859-e446-417b-8e36-ff346672a865%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
