I'm not sure how you would present a separation of logs without using stages to represent the agents in your multi-configuration project.
I thought that the way to see the separation of those logs was to have each parallel get its own stage declaration and then I can view the results for a specific stage from the "logs" pop-up that appears with each of the stages. For example, refer to https://ci.jenkins.io/job/Plugins/job/git-client-plugin/job/master/ to see how it presents the separation of Windows and Linux stages, and shows the console output for those stages. Test results are aggregated at the top level (like https://ci.jenkins.io/job/Plugins/job/git-client-plugin/job/master/73/testReport/) and do not seem to have a way to showing the results by stage. It would be a nice enhancement to have test results from a stage also visible in that stage in the old UI, but I'm not sure that would fit with the UI that is included in the stage "logs". Isn't the better investment to put effort into making those popular plugins fit well within the Blue Ocean UI? Mark Waite On Thu, Mar 30, 2017 at 4:29 AM <martinnyfl...@gmail.com> wrote: > I'm also in the same boat as you. Have you found a solution to this yet? > The Blue Ocean UI does mitigate the problem slightly, but I still find it > difficult to figure out what is going on. We use a large set of plugins > that does not show up in Blue Ocean (test and coverage graphs, console > parsing, etc.), so I would prefer to stick with the old UI for now. > However, I don't see any clear separation of the platforms unless I go > through the pipeline steps themselves. Another major challenge I'm having > is how to generate email reports. For matrix projects, we generate a report > summarizing errors, warnings, test results, etc. per platform. As far as I > see it, even the test results gets aggregated from all the platforms, > making it impossible to figure out at what node the test failed. This is > the pipeline I am currently working on: > https://github.com/martinmine/rootspi/blob/pipelines/jenkins/pipeline/continuous.groovy > > I'm also having the same feeling as you that there is something I'm > missing. I see many benefits of using pipelines (version control of the > build logic, generating artifacts, the dynamic build environment introduced > by scripting the pipeline, etc), but this is a major issue we need to get > across to properly utilize pipelines in our build infrastructure. > > > On Monday, August 29, 2016 at 11:46:55 PM UTC+2, Matt Hauck wrote: > > Hello! My team is looking to move to jenkins2 and struggling a bit with > how to do a multip-platform build. I'm really excited about the direction > it is moving in with the pipline builds -- I implemented something like > this myself (github.com/tanium/pyjenkins), but glad to see something > better being built directly into the platform. > > One difficulty I've run into so far is the less-than-ideal for > multi-platform builds with pipelines. We have a build that needs to run in > windows, linux, mac, etc. Right now we have this setup with a matrix job. > The only way I can see to do this with the pipeline plugin is using > `parallel` (i.e. > https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md#creating-multiple-threads > ) > > However, there is one rather large setback of doing it this way: *artifacts > and output get intermingled.* > > It is pretty crucial to us to be able to quickly and clearly tell which > platform the build failed on, as well as to distinguish the artifacts from > platform from the artifacts from another platform. I have the build > currently running with `parallel` steps, but I find it really really > difficult to find out what the build is doing either while running or after > it finishes. > > Also, there does not appear to be an option to setup an older-style matrix > build that uses the Jenkinsfile for its execution (for understandable > reasons), so I don't even see a way to move forward incrementally until > multi-platform builds have better support. > > I should also say that the matrix job is a really awesome feature of > jenkins that, from a survey of other build systems I did once, is kinda > unique to jenkins. Support for having the exact same build definition > across that executes across multiple platforms does not really exist > outside the matrix job definition in Jenkins, as far as I could tell. It > would be sad to see this great feature become a second-class citizen that > can't use all the cool shiny new toys. > > Are there plans to add better support for multi-platform builds / matrix > jobs? Is there something I'm missing? > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/06da6375-1697-48eb-a813-4bee345916a5%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/06da6375-1697-48eb-a813-4bee345916a5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtHuT5PGP%3Df5NgoTa5%2BR%2Be6ex3HywTEY%2BB_mwLe%2BKztyBw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
