[JIRA] [copyartifact-plugin] (JENKINS-26802) Copying artifacts from many projects
yannack created JENKINS-26802 Copying artifacts from many projects Issue Type: Bug Assignee: Unassigned Components: copyartifact-plugin Created: 05/Feb/15 10:52 AM Description: It would really be very useful to be able to specify multiple projects to copy from in a single copy artifact box. We have very complex pipelines, and copy artifacts from up to 10 upstream projects, each time using two copies (once to get the latest from our stable release, then once to get the latest from our dev branch but optional, because it may or may not exit). So we end up with up to 20 boxes, making the page super slow, hard to maintain, hard to visualize. If we could select multiple projects in the copy artifact line, which all would be copied using the same settings (optionality, filters, etc.), it would make life much easier. Checking the list of projects would be much simpler, adding one to both copy "strategies" would also be trivial (copy paste the modified line), etc. Project: Jenkins Priority: Minor Reporter: yannack 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] [gerrit-trigger] (JENKINS-11409) Gerrit-trigger should support waiting for downstream jobs of triggered builds
yannack commented on JENKINS-11409 Gerrit-trigger should support waiting for downstream jobs of triggered builds OK, I have just submitted a pull request adding this feature. I hope it makes it into the plugin soon. It works by adding a "delayed approval" setting to the Gerrit Trigger. When this is selected, the triggered job no longer auto-submits its result. Instead, there is a post-build action available which the downstream job will have to run. It needs to have a job name and a build number as a parameter, so these will need to be passed on as build variables. So as to solve the above problem of waiting forever, the "flexible publish" plugin can be used. Set it so you only do the delayed approval on your upstream project if it fails (thus not triggering downstream). In the most downstream project you can set it to always do the delayed approval. As you see this is still pretty manual, but it is a first draft, and has the benefit of working If there is enough interest, it can always be improved on later 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] [gerrit-trigger] (JENKINS-11409) Gerrit-trigger should support waiting for downstream jobs of triggered builds
yannack commented on JENKINS-11409 Gerrit-trigger should support waiting for downstream jobs of triggered builds The problem with the parametrized-plugin-blocking-buildstep solution is also that you cannot copy artifacts, as artifact copying is only possible in the post build. This means that all the features around artifacts are lost (md5s, etc). The solution mentioned by Kohsuke, item #2 specifically, with UpstreamCause, would unfortunately not work for me, as the Upstream cause of the build does not pass through buildFlow. I believe one of the challenges here is what to do if the job / promotion you are waiting for never triggers ? For example, if you have some build which fails, it may not trigger downstream, and the "end" job might not happen. This means there will probably have to be a way to manually terminate the gerrit operation in case what is expected doesn't happen. Otherwise, you may end up with a lot of "open" gerrit events, waiting for jobs which may well never be triggered. One option I have been thinking of would be to have in the post-build phase, an action: 'fail/approve the triggering Gerrit event with ID: ', and allow a parameter. You would have to pass the Gerrit-event ID via build parameters for instance, but parameters are very well supported. This is sufficiently flexible for most use-cases I believe. optionally, we could even imagine: the fail/approve is directly related to the outcome of the build phase (have an option for "stable build only"). Failure = fail gerrit, Success = OK Gerrit, Unstable = OK Gerrit the fail/approve is manually set (to use is more complex constructs, such as promotions, etc). 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.
