[JIRA] (JENKINS-47286) Support skipping stages in scripted pipelines for nice visualization in blue ocean and classic UI stage view
Title: Message Title Patrice Matignon commented on JENKINS-47286 Re: Support skipping stages in scripted pipelines for nice visualization in blue ocean and classic UI stage view I find unfortunate that the ticket be rejected wholesale. I think it had 2 things potentially in its scope that could be considered independently, and both of them are pretty common sense IMHO. The first part is adding support for skipped stages (i.e. add an _expression_ to the stage to determine whether to skip or not), which was shutdown, sadly. The second part is concerned solely on rendering a skipped stage in a pipeline visualization (classic or blue ocean). This applies to declarative pipelines right now, and I can't think there would be anyone arguing against it. IF skipped stages are one day available on scripted pipelines, the same rendering would apply as well. Would there be support for splitting this ticket maybe ? Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-47286) Support skipping stages in scripted pipelines for nice visualization in blue ocean and classic UI stage view
Title: Message Title Patrice Matignon updated an issue Jenkins / JENKINS-47286 Support skipping stages in scripted pipelines for nice visualization in blue ocean and classic UI stage view Change By: Patrice Matignon Created as response to comments of https://issues.jenkins-ci.org/browse/JENKINS-37781 as the visualization of skipped stages is very, very nice for declarative pipelines in Blue Ocean. # Allow to skip stages in scripted pipelines leading to equally nice visualization in Blue Ocean: The current approaches mentioned by [~mkobit] in https://issues.jenkins-ci.org/browse/JENKINS-37781?focusedCommentId=294965&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-294965 and [~jamesdumay] in https://issues.jenkins-ci.org/browse/JENKINS-37781?focusedCommentId=294966&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-294966 lead to either misleading or just less obvious visualization... # Improve visualization of stage view: instead of showing skipped stages (declarative pipelines) as always being green and allegedly executed, make them e.g. gray. ** Stage "skipped" is actually skipped, but stage view shows: !classic-ui-stage-view-1.png|thumbnail! ** This is IMHO also an IMHO a major enhancement and valid fix for the other problem reported by [~mkobit] in https://issues.jenkins-ci.org/browse/JENKINS-37781?focusedCommentId=294965&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-294965: "[The Pipeline Stage View Plugin] has some weird display issues if new pipelines have different stage executions than previous ones." Add Comment
[JIRA] [delivery-pipeline-plugin] (JENKINS-26210) Configure Jobs to be hidden from the delivery pipeline
Title: Message Title
Patrice Matignon commented on JENKINS-26210
Re: Configure Jobs to be hidden from the delivery pipeline
FWIW, I think this is closed a bit unfairly. This proposed code change doesn't alter the default behavior, where all the jobs will be shown. It only kicks in when the pipeline is configured to specifically hide jobs. I think the use case(s) for it were laid out pretty convincingly, I know that some jobs in my pipelines have no value for the target audience and are therefore distracting/confusing. Also, there were some suggestions to ease some of the given concerns - mine was to have a blinking indicator ("hidden job running") on the pipeline instance, when a hidden job is executing in the background. It can be easily adapted to show a status (red/blue) as well as a toggle button to show the hidden jobs if desired. Design-wise, if a job is preferred to be hidden, it probably doesn't matter to the pipeline audience whether it succeeded or failed. For my use cases, the jobs I want to hide are not in-between visible jobs, they are side-branches or leaves of the pipeline tree anyway. It would not be making a lot of sense to hide jobs on the pipeline critical path(s) I'd have to agree.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-alias-setter-plugin] (JENKINS-30426) Allow overwrite of aliases
Title: Message Title Patrice Matignon commented on JENKINS-30426 Re: Allow overwrite of aliases OK, that blew my mind quite a bit. Thank you very much Oliver! Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-alias-setter-plugin] (JENKINS-30426) Allow overwrite of aliases
Title: Message Title Patrice Matignon edited a comment on JENKINS-30426 Re: Allow overwrite of aliases This issue is affecting my set up and I would like to see this fix being released. Anyway Is thee any way that I can help ? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-alias-setter-plugin] (JENKINS-30426) Allow overwrite of aliases
Title: Message Title Patrice Matignon commented on JENKINS-30426 Re: Allow overwrite of aliases This issue is affecting my set up and I would like to see this fix being released. Anyway I can help ? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline-plugin] (JENKINS-26210) Configure Jobs to be hidden from the delivery pipeline
Title: Message Title Patrice Matignon commented on JENKINS-26210 Re: Configure Jobs to be hidden from the delivery pipeline @amanica : regarding your last suggestion "Another option is to actually show any 'hidden' jobs when they are actually running but hide them otherwise, this would make the pipeline reshuffle all the time which will not be very nice though" : I'm not crazy about the idea. I think they should be always hidden, or maybe a compromise is to allow a toggle on the UI "show/hide hidden jobs" (default: hidden"). If the concern is that the pipeline instance may be "active" because hidden jobs are still running (but the display pipeline instance shows no activity / all jobs complete), then maybe there could be a small blinking indicator of some kind, when (downstream) jobs are executing though not shown. Could be combined with the show/hide button discussed above. But for my use case, it would be superfluous. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline-plugin] (JENKINS-25891) Ability to link to individual pipeline
Title: Message Title Patrice Matignon commented on JENKINS-25891 Re: Ability to link to individual pipeline Just a possible implementation idea: this could be done relatively simply, by generating html anchors for each pipeline instance, and probably some sort of visual highlighting of the designated pipeline (e.g., a backgroung color). As mentioned above, if the pipeline instance is not in the standard top-n view, then the view should be expanded automatically (there is also a pagination ticket that could be related). Alternatively, an individual pipeline link could represent only this one pipeline. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline-plugin] (JENKINS-22482) Display pipeline total build time
Title: Message Title Patrice Matignon commented on JENKINS-22482 Re: Display pipeline total build time Thank you all for this great feature, very useful! I am using v0.9.5 and I see that the build times are reported as the sum of the build times for all steps. However, earlier in this thread, there was a discussion about the concurrent steps that should not be counted twice. So in this version, it does not seem to be implemented. Could you please clarify? And if confirmed, what is the general sense of what the logic should be? IMHO, I see value in different scenarios: Actual build times, excluding concurrent steps (i.e. actual time spent building steps) Total end-to-end times (pipeline time to complete), including the inactive time in case of MANUAL triggers So, and realizing this adds complexity, maybe a configuration for potentially multiple displays: [ ] show total build times [ ] show actual build times [ ] show end-to-end pipeline duration What is your sense, so that we can decide if a follow-up enhancement ticket should be created ? Thanks in advance! Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [htmlpublisher-plugin] (JENKINS-29944) Existing project-level report shouldn't disappear when report is not generated
Title: Message Title Patrice Matignon created an issue Jenkins / JENKINS-29944 Existing project-level report shouldn't disappear when report is not generated Issue Type: Improvement Assignee: mcrooney Components: htmlpublisher-plugin Created: 14/Aug/15 1:38 AM Environment: HTML Publisher plugin v1.5 Jenkins v.1.580.1 Labels: htmlpublisher reporting Priority: Major Reporter: Patrice Matignon I have the HTML Publisher plugin configured to keep only one copy of the report (project-level) and to not fail if the report is missing. However, when the report is actually missing, the existing report is wiped out and the link disappears altogether from the project page. I believe it should not behave this way, and preserve the existing report if a new report is not available, regardless of the success/failure status of the last job.
[JIRA] [jacoco-plugin] (JENKINS-27766) Jacoco with Jenkins on Apache Tomcat: /jacoco/classes does not exist
Title: Message Title Patrice Matignon commented on JENKINS-27766 Re: Jacoco with Jenkins on Apache Tomcat: /jacoco/classes does not exist FWIW, I seem to be getting this error when the job config provides a "classes dir" that does not exist in my workspace (or is not created by the build). It is annoying that it would crash an otherwise good build simply because this configuration is incorrect. Other plugin handles this more gracefully with a simple warning rather than a build breaking exception. this even occurs when the plugin couldn't even find .exec files to begin with (so it shouldn't have to worry about the classes dir, or generating the report right ?) Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [jacoco-plugin] (JENKINS-27297) Using jacoco is drastically increasing Jenkins historical builds folder size
Title: Message Title Patrice Matignon edited a comment on JENKINS-27297 Re: Using jacoco is drastically increasing Jenkins historical builds folder size Agreed. Also, similarly to other plugins dealing with large reports, there should be an option to only preserve the full report for the (few? configurable?) last (successful?) build(s). There is usually no need to preserve the complete history of JaCoCo detailed coverage reports, though the trend is evidently important. so So this would have the advantage of keeping the size fo the builds folder stable and manageable. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [jacoco-plugin] (JENKINS-27297) Using jacoco is drastically increasing Jenkins historical builds folder size
Title: Message Title Patrice Matignon commented on JENKINS-27297 Re: Using jacoco is drastically increasing Jenkins historical builds folder size Agreed. Also, similarly to other plugins dealing with large reports, there should be an option to only preserve the full report for the (few? configurable?) last (successful?) build(s). There is usually no need to preserve the complete history of JaCoCo detailed coverage reports, though the trend is evidently important. so this would have the advantage of keeping the size fo the builds folder stable and manageable. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-alias-setter-plugin] (JENKINS-25566) Don't create multiple aliases with a single build
Patrice Matignon commented on JENKINS-25566 Don't create multiple aliases with a single build Yes, I understand the reason for doing it at the beginning and then again at the end - I'm fine with that. I'd simply like to discard/clean-up the first alias if the second pass creates a different link, to keep things tidy. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-alias-setter-plugin] (JENKINS-25566) Don't create multiple aliases with a single build
Patrice Matignon created JENKINS-25566 Don't create multiple aliases with a single build Issue Type: Improvement Assignee: Oliver Gondža Components: build-alias-setter-plugin Created: 12/Nov/14 2:12 PM Description: Exceprt form the online help: "The update actually happens twice during the build; once right after the check out, and once before the build is completed." As a result, when setting the build alias, you cna end up with 2 aliases if the information you use, is not available on the first pass (or change before the second pass). Normally I would think you only want the final version (that is my use case), and would like to see the plugin cleanup the first alias when it differs from the second one. (maybe some other users would prefer to have a checkbox config item to be able to preserve both ?) Project: Jenkins Priority: Major Reporter: Patrice Matignon This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-16361) @Grab Grape support
Patrice Matignon commented on JENKINS-16361 @Grab Grape support Thanks for the quick reply. I had missed this ticket was indeed for the job-dsl-plugin. I will try what you suggest. Cheers! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-16361) @Grab Grape support
Patrice Matignon commented on JENKINS-16361 @Grab Grape support Any indication of which version of Jenkins this is/will be available ? Also, does it matter whether the @Grab annotation is used from within the System console or a Groovy build step ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [jira] (JENKINS-22004) JIRA does NOT create new ticket for build failure for a new build project.(Create new issue plugin bug). Occurs when the new job build results are all failures
Patrice Matignon commented on JENKINS-22004 JIRA does NOT create new ticket for build failure for a new build project.(Create new issue plugin bug). Occurs when the new job build results are all failures Is it more like a feature where the JIRA plugin will not create additional JIRA tickets for a consecutive failures of a build ? IF so, it probably would have been good to provide an option, but this is probably a decent default behavior if you must have one. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-alias-setter] (JENKINS-24680) Assign an alias to a build manually
Patrice Matignon created JENKINS-24680 Assign an alias to a build manually Issue Type: New Feature Assignee: Oliver Gondža Components: build-alias-setter Created: 11/Sep/14 6:49 PM Description: The idea would be to select a build via the standard Jenkins UI, and assign an arbitrary (subject to input validation) alias to it, i.e. the build page is now available thru a url utilizing the new alias (as you would expect from an alias that has been automatically assigned during the actual build). Fancy: detect if this alias is already used (by another build), offer to move it to the present build. (btw, it would be nice to be able to "revoke" an existing alias, whether previously assigned manually or automatically). This feature would be useful for manual processes around build promotion or build marking. Project: Jenkins Priority: Minor Reporter: Patrice Matignon This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [sidebar-link] (JENKINS-23605) Support for sidebar links
Patrice Matignon resolved JENKINS-23605 as Fixed Support for sidebar links Fixed at least in v0.8.1, possibly before that. Change By: Patrice Matignon (06/Sep/14 5:30 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-23605) Support for sidebar links
Patrice Matignon commented on JENKINS-23605 Support for sidebar links It's actually working for me now (still not using the CB Folders plugin), I think this ticket should be closed. If you think it should be reopened until the PR above is merged into the sidebar-link plugin, feel free to do so. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-22482) Display pipeline total build time
Patrice Matignon commented on JENKINS-22482 Display pipeline total build time I would love to see this feature come to fruition. Let me know if I can help. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-23485) TokenMacro for getting a version value stored in environment variable
Patrice Matignon commented on JENKINS-23485 TokenMacro for getting a version value stored in environment variable Actually, I see that for my very use case, there is an existing ticket already created: https://issues.jenkins-ci.org/browse/JENKINS-20608 So I suppose I'm still not clear what this ticket right here is requesting. Much sorry for the noise. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-23485) TokenMacro for getting a version value stored in environment variable
Patrice Matignon commented on JENKINS-23485 TokenMacro for getting a version value stored in environment variable I'd be interesting in this enhancement, with my particular use case being the "Stage Name", "Task Name" fields, where these two could have dynamic values based on Job Parameters. On a side note, I feel that the title of this JIRA ticket could be made more specific. It wasn't explicit to me where usage of the Token Macro was requested for instance. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-23605) Support for sidebar links
Patrice Matignon commented on JENKINS-23605 Support for sidebar links That is interesting, I don't have the CB Folders plugin actually. I am on 1.543 so I'll try to update to a recent version and re-test. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-23605) Support for sidebar links
Patrice Matignon commented on JENKINS-23605 Support for sidebar links The steps are to install the Delivery Pipeline plugin, and also install the Sidebar-links plugin. Then In Manage Jenkins -> Sidebar links, define some arbitrary links and Save. These links normally show in the left margin for most views (they are global in the current version). But wiht the Delivery Pipeline plugin, they don't show. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-23605) Support for sidebar links
Patrice Matignon updated JENKINS-23605 Support for sidebar links Change By: Patrice Matignon (04/Aug/14 5:18 PM) Description: The Sidebar-links plugin lets the admin define custom links showing in the left margin area. This works fine in most view types, but the delivery pipeline views do not display these links unfortunately.Quick note (may or may not be relevant to the fix here) a pending improvement for the sidebar-link plugin is to allow per-view links, or custom inks links that are specific to each view (currently, it's global for all views), so most likely the Edit View screen will have to include a section provided by the sidebar-link plugin. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-23605) Support for sidebar links
Patrice Matignon updated JENKINS-23605 Support for sidebar links Change By: Patrice Matignon (27/Jun/14 5:50 PM) Labels: link sidebar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-23605) Support for sidebar links
Patrice Matignon created JENKINS-23605 Support for sidebar links Issue Type: Bug Affects Versions: current Assignee: Patrik Boström Components: delivery-pipeline, sidebar-link Created: 27/Jun/14 5:49 PM Description: The Sidebar-links plugin lets the admin define custom links showing in the left margin area. This works fine in most view types, but the delivery pipeline views do not display these links unfortunately. Quick note (may or may not be relevant to the fix here) a pending improvement for the sidebar-link plugin is to allow per-view links, or custom inks that are specific to each view (currently, it's global for all views), so most likely the Edit View screen will have to include a section provided by the sidebar-link plugin. Project: Jenkins Priority: Minor Reporter: Patrice Matignon This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-alias-setter] (JENKINS-20405) When an alias is re-assigned to a newer build, the alias url should no longer point to the older build
Patrice Matignon commented on JENKINS-20405 When an alias is re-assigned to a newer build, the alias url should no longer point to the older build Yes, but the list of alias will become long and unsightly on the UI. And selecting the desired alias from that list of duplicates does not resolve to the latest, because they are direct hyperlinks to the numbered builds (so each duplicate of the alias points to a different build thru its canonical url). I would like the UI to be fixed to treat the 'pseudo-permalinks' (like lastStableBuild, lastSuccessfulBuild, and the custom last[Status][Moniker]) differently form the other aliases: be listed with the moniker url, and resolved only when the build is requested. While the other aliases can stay as is, I think it would be better to also delay resolution of the alias. However, it could affect the rendering performance of the Project page since it needs to 'curates' the pseudo permalinks. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-alias-setter] (JENKINS-21734) When a job is copied, the aliases as copied over and corrupt the new job
Patrice Matignon commented on JENKINS-21734 When a job is copied, the aliases as copied over and corrupt the new job I agree This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-22423) Pipelines are mixed up when same stage/step names are used
Patrice Matignon commented on JENKINS-22423 Pipelines are mixed up when same stage/step names are used It works great for me as well. Thank you for the quick fix! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-22423) Pipelines are mixed up when same stage/step names are used
Patrice Matignon commented on JENKINS-22423 Pipelines are mixed up when same stage/step names are used My apologies, I could restart my instance. Still trying to do this asap to get you feedback. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-22423) Pipelines are mixed up when same stage/step names are used
Patrice Matignon commented on JENKINS-22423 Pipelines are mixed up when same stage/step names are used Thanks much (that was fast!) I'll test it today. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-22423) Pipelines are mixed up when same stage/step names are used
Patrice Matignon updated JENKINS-22423 Pipelines are mixed up when same stage/step names are used Change By: Patrice Matignon (31/Mar/14 4:47 AM) Attachment: Pipelines-for-Multiple-Branches.png.jpg This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-22423) Pipelines are mixed up when same stage/step names are used
Patrice Matignon created JENKINS-22423 Pipelines are mixed up when same stage/step names are used Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: delivery-pipeline Created: 31/Mar/14 2:22 AM Description: I have multiple pipelines representing multiple maintenance branches of the same codebase, and each pipeline has the same stage names and step names. They are all using different projects though (all projects are duplicated for each branch/pipeline). What happens is that the top pipeline has the proper arrows in the view, and the bottom one has all the arrows from the first stage going all the way up to the second stage of the top pipeline (the remaining stages on the bottom pipeline just have no arrow/lines). All pipelines in between the top and bottom ones have no arrow/lines. If I add a completely different pipeline at the bottom, then it won't have any lines/arrows at all, but it won't point to the top pipeline, so I think it's related to the fact that I'm using the same stage/step names. This is a regression, it was working fine before version 0.7.1 (which had only the top pipeline displayed) Environment: Linux SLES 11.2 Jenkins 1.543 Project: Jenkins Priority: Major Reporter: Patrice Matignon This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-22211) Parallel stages display distorted
Patrice Matignon commented on JENKINS-22211 Parallel stages display distorted Then again, I have no parallel stages, so this is not the proper JIRA, my apologies This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-22211) Parallel stages display distorted
Patrice Matignon commented on JENKINS-22211 Parallel stages display distorted This is still not working for me, with version 0.7.2. I have multiple pipelines representing multiple maintenance branches of the same codebase, and each pipeline has the same stage names and step names. They are all using different projects though (all projects are duplicated for each branch/pipeline). What happens is that the top pipeline has the proper arrows in the view, and the bottom one has all the arrows from the first stage going all the way up to the second stage of the top pipeline (the remaining stages on the bottom pipeline just aren't part of the graph). All pipelines in between the top and bottom ones have no arrow/lines. If I add a completely different pipeline at the bottom, then it won't have any lines/arrows at all, but it won't point t the top pipeline, so I think it's related to the fact that I'm using the same stage/step names. This is a regression, it was working fine before version 0.7.1 (which had only the top pipeline displayed) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [delivery-pipeline] (JENKINS-22210) On restarting broken build in pipeline, dashboard should update accordingly
Patrice Matignon commented on JENKINS-22210 On restarting broken build in pipeline, dashboard should update accordingly I am interested in having a fix for when using the "Rebuild" plugin. Is it the same root cause essentially (i.e. the upstream cause is not present/preserved) ? I think the combo (pipeline + rebuild plugins) is powerful and adds a lot of value. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-alias-setter] (JENKINS-21734) When a job is copied, the aliases as copied over and corrupt the new job
Patrice Matignon created JENKINS-21734 When a job is copied, the aliases as copied over and corrupt the new job Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: build-alias-setter Created: 10/Feb/14 3:10 AM Description: When a job with aliases is used as a copy for a new job, the build aliases are copied over to the new project. It might not fail immediately, but at the very least the job can't be reloaded from disk and it can't be found. Sample from system logs include: Failed Loading job XX (new job) java.lang.NullPointerException at java.util.Vector.addAll(Vector.java:880) at hudson.model.AbstractProject.createTransientActions(AbstractProject.java:756) at hudson.model.Project.createTransientActions(Project.java:213) at hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:749) at hudson.model.AbstractProject.onLoad(AbstractProject.java:336) Feb 09, 2014 7:03:14 PM INFO jenkins.InitReactorRunner$1 onAttained Loaded all jobs Environment: Linux SLES 11.2; Jenkins v1.543 Project: Jenkins Labels: job copy-job build-alias Priority: Major Reporter: Patrice Matignon This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [purge-build-queue] (JENKINS-21674) After purging, the user should be taken back to the main (home) page
Patrice Matignon created JENKINS-21674 After purging, the user should be taken back to the main (home) page Issue Type: Bug Affects Versions: current Assignee: jieryn Components: purge-build-queue Created: 05/Feb/14 10:49 PM Description: After pressing the "Purge" button, the queue is purged as expected, bu tthe user is taken back to the same page with the "Purge" button. This is misleading as a user might not realize that the Queue is already purged (there is no feedback) and press the button repeatedly. Ideally, after purging, the app should take the user back to the home page. In the code, it navigates back to the previous page, but this being the submit for the purge button, the previous page ends up being the same page. Project: Jenkins Labels: usability navigation Priority: Minor Reporter: Patrice Matignon This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [delivery-pipeline] (JENKINS-21291) Loading animation for first load of the view
Patrice Matignon updated JENKINS-21291 Loading animation for first load of the view Re-qualifying from bug to improvement Change By: Patrice Matignon (11/Jan/14 10:19 PM) Issue Type: Bug New Feature This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [delivery-pipeline] (JENKINS-21149) Possibility to change pipeline version in later tasks or stages
Patrice Matignon edited a comment on JENKINS-21149 Possibility to change pipeline version in later tasks or stages What should be the logic for setting the version then ? If I understand correctly, using "Create Delivery Pipeline version" sets an env variable "PIPELINE_VERSION", and also passes it on as a build parameter to jobs downstream, whether or not the "set Build display name" is actually checked. Also, currently the default behavior is to use the first build's display name (whether or not it was set by the mechanism above) as the pipeline instance version. I would propose that the pipeline would look at the PIPELINE_VERSION env variable, starting from the end of the pipeline and moving backwards if necessary (to reflect the fact that you can set/override the pipeline version later in the pipeline). If that env var is not found anywhere in the pipeline instance builds, then the logic would default to the current behavior, in order to maintain backward-compatibility. Does that sound sensible? Thanks for your feedback! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [delivery-pipeline] (JENKINS-21149) Possibility to change pipeline version in later tasks or stages
Patrice Matignon edited a comment on JENKINS-21149 Possibility to change pipeline version in later tasks or stages What should be the logic for setting the version then ? If I understand correctly, using "Create Delivery Pipeline version" sets an env variable "PIPELINE_VERSION", and also pass it on as a build parameter downstream, whether or no the "set Build display name" is checked or not. Also, currently the default behavior is to use the first build's display name (whether or not it was set by the mechanism above). I would propose that the pipeline would look at the PIPELINE_VERSION env variable, starting from the end of the pipeline and moving backwards if necessary (to reflect the fact that you can set/override the pipeline version later in the pipeline). If that env var is not found anywhere in the pipeline instance builds, then the logic would default to the current behavior, in order to maintain backward-compatibility. Does that sound sensible? Thanks for your feedback! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [delivery-pipeline] (JENKINS-21149) Possibility to change pipeline version in later tasks or stages
Patrice Matignon commented on JENKINS-21149 Possibility to change pipeline version in later tasks or stages What shoudl be the logic for setting the version then ? If I understand correctly, using "Create Delivery Pipeline version" sets an env variable "PIPELINE_VERSION", and also pass it on as a build parameter downstream, whether or no the "set Build display name" is checked or not. Also, currently the default behavior is to use the first build's display name (whether or not it was set by the mechanism above). I would propose that the pipeline would look at the PIPELINE_VERSION env variable, starting from the end of the pipeline and moving backwards if necessary (to reflect the fact that you can set/override the pipeline version later in the pipeline). If that env var is not found anywhere in the pipeline instance builds, then the logic would default to the current behavior, in order to maintain backward-compatibility. Does that sound sensible? Thanks for your feedback! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [thinBackup] (JENKINS-20837) Differential backups should not cause Jenkins to stop running new jobs
Patrice Matignon commented on JENKINS-20837 Differential backups should not cause Jenkins to stop running new jobs I also run into the same problem for the same scenarios described in this ticket. And I like the proposed solution, as long as only the running builds, and not the whole job where at least one build is currently running, are skipped. In other words, I would want to make sure that my job configuration in particular, is backed up regardless. I believe this is what the description is indeed saying but I wanted to be explicit about that. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [thinBackup] (JENKINS-21221) Add option for backing up of plugin archives, as well as arbitrary files
Patrice Matignon commented on JENKINS-21221 Add option for backing up of plugin archives, as well as arbitrary files There is nothing wrong with backing up only the metadata, it's fast and storage-efficient for sure. As a matter of personal preferences, I prefer having the option of a full backup for a more straight-forward restore. I am looking at the following potential benefits: offline restore, with no or controlled connectivity to the internet 'manual' restore where the backed up ZIP can be restored manually to recreate an instance. That's also arguably an added safeguard that the restore should always be possible. When the plugin mix includes some internally-developed plugins that were installed by uploading a .jpi/.hpi file, that can't be found on an update site. By storing the .hpi/.jpi files along with the .disabled marker files, we can restore the exact plugin mix, including the plugins that were temporarily disabled. At least I don't believe the standard way allows for this. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [thinBackup] (JENKINS-21221) Add option for backing up of plugin archives, as well as arbitrary files
Patrice Matignon created JENKINS-21221 Add option for backing up of plugin archives, as well as arbitrary files Issue Type: Improvement Affects Versions: current Assignee: Patrice Matignon Components: thinBackup Created: 04/Jan/14 1:31 AM Description: Until now, plugins are archived as a list which makes Jenkins, when restored, re-download and re-install the plugins. Alternatively, there should be an option to archive the actual plugin archives themselves. Also, It is not possible to archive arbitrary files that aren't selected by the built-in filters. It would be useful to allow for an arbitrary regex pattern to select additional files, since oftentimes plugins use config files that fall outside of the backup set. Project: Jenkins Labels: plugin thinbackup plugins backup restore Priority: Minor Reporter: Patrice Matignon This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [delivery-pipeline] (JENKINS-21149) Possibility to change pipeline version in later tasks or stages
Patrice Matignon commented on JENKINS-21149 Possibility to change pipeline version in later tasks or stages Thanks Patrik! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [delivery-pipeline] (JENKINS-21070) "Set build displayname" does not work
Patrice Matignon commented on JENKINS-21070 "Set build displayname" does not work Thanks for the quick feedback Patrick. Yes, I have some "pre-release" tasks in the first stage, that can't really determine the pipeline version yet (at least not the way I want it). Also, if any job in the pipeline has the "Set Delivery Pipeline Version" section in its configuration, it implies that the pipeline version could be set/reset at any time during the build flow within that instance. And why couldn't it ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [delivery-pipeline] (JENKINS-21070) "Set build displayname" does not work
Patrice Matignon commented on JENKINS-21070 "Set build displayname" does not work So in effect, for any other job in the pipeline this function is ineffective? If so, I think this restriction 1) is not made very clear ; and 2) might not be fully justified. If you agree, I could enter a couple different JIRA's. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [delivery-pipeline] (JENKINS-21070) "Set build displayname" does not work
Patrice Matignon commented on JENKINS-21070 "Set build displayname" does not work Also, not sure if I'm doing it wrong, but the Version associated with each pipeline instance is not set either, it seems to be stuck with the build name of the first build job in the pipeline. Would this be related ? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
