I would hope this would also support the same for scripted pipelines too.

+100  Today, I am stucked to run different kind of tests (python, qtest, ...) in parallel on two configurations (Windows and Linux) in parallel.

This picture demonstrates it better... running parallel within parallel without a step before makes no sense since you could just run them in the outer parallel task.

https://issues.jenkins-ci.org/secure/attachment/36602/pipeline_mockup.png

digaus Actually the complete idea from Ben Dean would be really nice to have. Check this comment here:

https://issues.jenkins-ci.org/browse/JENKINS-38442?focusedCommentId=292647&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-292647

It would be nice to have that not only for the declarative, but also the scripted pipeline.

Sometimes the test suites to cover are not statically declared and can depend on different things for different branches, hens the need for the scripted pipeline.

We need this for the scripted pipeline as well.

Is there any progress on this task? My team has a highly parallel flow that requires multiple layers of nested parallels. It would make life easier for debugging purposes if this feature were implemented.

same here - i have a 50+ different build configs to run in parallel, a dozen per OS (Linux, MacOS, iOS, Android, Windows . . .) - Blue Ocean graph is pretty useless this way . . .

This feature will help us a lot.

Multiple levels of parallelizm are currently supported only by creating new jobs, which is a poor solution given that Jenkins groovy supports it out of the box.

I'm sure this feature will help a lot of users since many applications test themselves on multiple platforms today.

shahafd I'm not sure that you are talking about the BlueOcean plugin.

Jenkins pipeline already supports multiple levels of parallelism, this is only about Blue Ocean's UI

asavanchuk - I am talking about the BlueOcean plugin.

We work with BlueOcean and we have multiple levels of parallelizm in our pipeline, and the only method to show it correctly using the GUI is creating multiple jobs for the different paltforms, otherwise it shows all of the parallel steps in the internal parallel block in the same level of the parallel steps of the external parallel block which is obviously wrong, furthermore, it also shows the serial steps of the internal job as parallel.

For example - we have the following pipeline:

Parallel:

    Linux:

        Build

        Parallel:

            Fixed tests

            Custom tests

    Windows:

        Build

We currently create a different job for windows and linux pipes and trigger them from the master job.

When trying to run it in a single job, BlueOcean shows it as follows:

Parallel:

    Linux

    Fixed tests

    Custom tests

    Windows

I would very much like to see it as shown in JENKINS-38442 (pipeline_mockup.png)

Our team is also hoping for a solution to this, the setup we have is similar to what shahafd describes, starting with some sequential pre-work, then splitting into windows and linux build, then ideally further splitting several times down the pipeline (multiple tests that each is parameterized over OS and HW configurations and fully parallelizable).

Right now our pipeline takes three times as long as it should because we really like to have the user friendly visualization we get from Blue Ocean. This is of course not ideal because time to failure is longer that it should be and the dev cycle time suffers.

I think this issue should add support for any levels of parallelism, not hard code it for any arbitrarily magic number of parallelism.

The issue should be renamed to "Support nested parallel stages"

I also agree that the "pipeline_mockup.png" in JENKINS-38442 looks like the natural way to render this and it should scale well. Rendering the X(1 for example) top level parallel stages different then the N-X inner levels, as I have seen proposed, seems like a hack tailored to some specific use case.

My set up is also very similar to the one that shahafd has described.

A possible solution is to combine all nested stages into one node. When you click on this node, it expands and shows you everything else that was under it. This way the view is fairly clean and intuitive to use. See following images for examples:

In the image below lets imagine I clicked on build 1:

The UI will then transition to show the following nested pipeline:

This basically steps away from only supporting nested parallels to just supporting nested pipelines.

Is there anyone who can be considered the owner of this issue? It would be great if we could come up with a plan and start executing. As  shahafd  said, when you have 50+ builds in parallel, the UI is pretty much useless without nesting support.

Could someone from cloudbees possibly take a look at this? I have seen a few other tickets related to parallel visualization in blue ocean owned by you guys.

The essence of this issue is a mismatch between the ability to express a nested (and valid) workflow in the Jenkinsfile and the UI's ability to render it.  I don't know of a limit on nesting in the Jenkinsfile, so it follows that there shouldn't be such a limit in the UI either.

To me, the significance of this issue is that BlueOcean is used for CI – its job is to help us execute, understand, and troubleshoot some complex procedures in dev/release.  Failing to represent the procedure itself undermines this entire concept.

Is it possible to bump the priority of this issue to a blocker or do we need someone special to do that?

I am bumping priority to blocker. Please let me know if this is something that I was not allowed to do.

Hopefully, this will bring a little more attention to this issue.

I am looking forward parallel in parallel feature, whole code of declarative syntax.

This is a very important issue for us to be resolved. Without this our pipeline takes so much longer to complete, since almost everything has to be done in series instead of parallel. 

I'm surprised this isn't supported by the UI.

We develop firmware and cross-compile to different architecture using agent of different OS. This equates to a lot of builds in parallels, with internal stages in parallel as well (such as static code analysis, running tests, etc.).

Parallelism is a must otherwise build times are way too long and a pain for developers who want rapid cycles of feedback and not wait for a build to complete.

Is there any reason why this issue doesn't get prioritized ?

It is already marked as a blocker for 6 months, and was critical for another 6 months earlier.

Can you please update on the status of this request ? Is it in development ? Do you plan to add this feature soon ?

It is very crucial for many people using BlueOcean plugin.

I think a better question to ask would be "what technical hurdles block this request".  My guess is that when you run things in parallel, each parallel item counts as a "stage" to the UI, and so what we are really discussing here is a need to support sub-stages – something that seems a bit more complicated than a UI fix.

Is that accurate? 

+1 I'm currently running 20 parallel stages in my pipeline for speed but the BlueOcean visualization of a tall column of nodes isn't the most user friendly. Nested parallel would be one solution to this. I'd also be happy with a purely UI construct to categorize my stages for better visualization. This has been mentioned in a series of tickets resolved as dupes that ultimately end up here. An example based on the description:

pipeline {
    agent none
    stages {
        stage('Parallel Stage') {
            parallel {
                stage('Stage 1') {
                    steps {
                        echo "Stage 1"
                    }
                }
                category('Stage 2') {
                    stage("Stage 2.1"): {
                        steps {
                            echo "Stage 2.1."
                        }
                    },
                    stage(Stage 2.2") {
                        steps {
                            echo "Stage 2.2."
                        }
                    }
                }
            }
        }
    }
}

Blueocean team - Any updates on this? Are you guys working on this issue since its a blocker for us?

• Adobe Developer

What I did as a workaround is building a parallel stage dynamically - 

We deploy 5 services for two clouds, we want to deploy all in parallel.  Let's say each service takes 5 min to deploy, we had to wait 10 minutes because we couldn't run two cloud stages in parallel that runs multiple services stages also in parallel:

So I built one parallel stage with all 10 services, and named each step with a relevant prefix:

stage('Deploy') {
                    steps {
                        script {
                            def parallelStagesMap = [:]
                                AWS_CLUSTER_NAME.collect {
                                   parallelStagesMap.put("AWS ${it}", buildUtils.Deploy('AWS', it))
                                }
                                GCP_CLUSTER_NAME.collect {
                                   parallelStagesMap.put("GCP ${it}", buildUtils.Deploy('GCP', it))
                                }

                             parallel parallelStagesMap
                        }
                    }
                }

That's a good workaround. I can't speak for everyone here, but my personal interest in this issue is more to do with the first attached screenshot in the original issue – the ability to have multiple sequential stages shown in each parallel branch. In other words, to not have it all squish horizontally into a single stage that represents the entire branch.

ianfixes I agree, I'm also waiting for this solution, that's what I did meanwhile until this issue will be resolved..

Is there a plan to update the visualization as shown in parallel-stages-new.png ? Or is it available in already in any of the new releases ?

Hi,

any update regarding this issue?

Having multiple levels of parallel stages would optimize the use of my executors and significantly reduce my pipeline times. 

This would be very helpful to me for stages that create multiple platform specific artifacts. When I do this now, I have to have one matrix stage that builds Windows and Linux packages (using creative use of Dockerfile agents, I'm able to get these to run in parallel), and one stage dedicated to building Mac packages. Because matrix stages seem to use up a parallel stage under the hood, I can only run these stages one after another, even though the physical servers could easily run these steps independently .  

that's a really important feature for our team as well. we have an optimized ci with multiple parallelized steps, which look really awkward without that capability

henryborchers in your case there's no limitation in using parallelism inside another. the downside is that it's really hard to view the process in the UI and in case of a failure step, the UI just don't understand how to show it.

Will this fix the problem of visually showing two parallel Pipelines we have now run into?

We have a Jenkinsfile which runs two Pipelines in serial. For efficiency these can be run in parallel, but that will not look good din Blue Ocean.
This is how the two Pipelines are visualized in Blue Ocean (The black circle is the first pipeline, the blue is the second).

This is how the two Pipelines are visualized when running them in parallel:

The Scripted Pipeline in Seriel:

def maven = new com.company.MavenBuild()
maven.executeBuild()
def gradle = new com.company.GradleBuild()
gradle.executeBuild()

The Scripted Pipeline in Parallel:

parallel {
    'Maven': {
        def maven = new com.company.MavenBuild()
        maven.executeBuild()
    },
    'Gradle': {
        def gradle = new com.company.GradleBuild()
        gradle.executeBuild()
    }
}

Here's a use case that might help with design.

Consider a typical pipeline that build an artifact[s] and deploys it to sequential environments (let's say Dev and QA for the sake of example).

Consider that you might want to deploy to multiple locations, for instance - to aws, azure and gcp. These are parallel independent worlds, so environments progression would be happening in parallel there.

Consider that within each location, you also want to deploy into multiple regions. Regions are also isolated independent worlds, so they would have to be deployed in parallel within it's location (aka aws, gcp, azure etc).

That creates at least two levels of nesting, but generally you can extrapolate this idea, for instance to deploy to each AZ separately, or maybe - deploy to multiple groups of locations or something like that, I do not see why there should be a limit of just two.

Anyway, here is a scripted pipeline representation of that use case (just two levels for the sake of simplicity):

 stage('Realms') {
    parallel 'aws': {
        stage('Regions (aws)') {
            parallel 'us-east-1 (aws)': {
                stage('Dev (aws us-east-1)') {
                    echo 'aws us-east-1 dev'
                }
                stage('QA (aws us-east-1)') {
                    input message: 'Approve aws us-east-1 qa?', ok: 'Approve aws us-east-1 qa!'
                    echo 'aws us-east-1 qa'
                }
            }, 'us-west-2 (aws)': {
                stage('Dev (aws us-west-2)') {
                    echo 'aws us-west-2 dev'
                }
                stage('QA (aws us-west-2)') {
                    input message: 'Approve aws us-west-2 qa?', ok: 'Approve aws us-west-2 qa!'
                    echo 'aws us-west-2 qa'
                }
            }, failFast: false
        }
    }, 'gcp': {
        stage('Regions (gcp)') {
            parallel 'us-east-1 (gcp)': {
                stage('Dev (gcp us-east4)') {
                    echo 'gcp us-east4 dev'
                }
                stage('QA (gcp us-east4)') {
                    input message: 'Approve gcp us-east4 qa?', ok: 'Approve gcp us-east4 qa!'
                    echo 'gcp us-east4 qa'
                }
            }, 'us-west-2 (gcp)': {
                stage('Dev (gcp us-west4)') {
                    echo 'gcp us-west4 dev'
                }
                stage('QA (gcp us-west4)') {
                    input message: 'Approve gcp us-west4 qa?', ok: 'Approve gcp us-west4 qa!'
                    echo 'gcp us-west4 qa'
                }
            }, failFast: false
        }
    }, failFast: false
}

Also consider a deployment stage itself (currently represented with just one simple echo step) - it will most likely have a lot of low level steps such as sh and so on. From the pipeline user perspective - it doesn't makes any sense to see all that implementation details. The user will want to see aggregation of steps at some level of abstractions, for instance if deployment is implemented with Terraform - the user will want to see things like plan, display diff and apply. The user might want to dig into any of these abstractions to the level of actual steps, of course, so that should be an expandable option.
I think implementing more than two levels of nesting using a use case from above will also solve that second use case.

Does anyone know if this is purely a visualization issue? or it is an issue with the underlying data structure? If someone was wanting to get started looking into this issue, where should they start?

gmtm, I get the feeling the project does not have anybody working on Blue Ocean development anymore. My guess is that whoever was in charge of it has left the company or moved on to other projects because I haven't seen any real improvements done to it in years. It's a shame because Blue Ocean was a GAME CHANGER!!! I personally love how Blue Ocean displays my pipeline and helps me quickly figure out an issue when something goes wrong.  However, it seems to have issues that don't aren't being addressed and missing features (like this one) that could make it much. (In addition, Blue Ocean takes a very long time to load!)

I would LOVE first-class support for multiple levels of parallelism (such as nested parallel commands or nested matrixes in the declarative pipelines). Having that would let me load-balance and greatly reduce the duration of my pipelines. However, it just doesn't seem like a priority for anybody who has the skills to do anything about it.

I don't blame anybody working on Jenkins. In fact, I love everything they do regardless if they address stuff that make my life better or someone else's. No, I just wish my own skills included what was needed to help out in the same way the Jenkins has helped me. 

Well said henryborchers. Additionally I would point out that classic UI does not have visualization support for parallel stages at all, in any shape or form, not even single leveled. It is all unreadable linear mess in the classic UI.

There hasn't been any active development on Blue Ocean for a while. See https://groups.google.com/g/jenkinsci-users/c/xngZrSsXIjc/m/-_aIrWyICgAJ.

The pipeline-graph-view-plugin is bringing the pipeline visualization from Blue Ocean into the classic UI. It might be worth creating a new issue for that plugin?

+100500 Jenkins shared libraries and Jenkinsfiles are awesome, but the UI around them is a terrible mess, especially when it comes to stage display and generally trying to understand what logs are where etc. I think it's easier to rewrite the UI for pipeline builds from scratch to somehow allow browsing through everything in a visually pleasing execution step graph, not a flat representation like a list or a table.

Is this still being worked on?