Very preliminary initial work up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/98 - right now it's just the infrastructure/parsing/schema/etc for making this work without actually testing the new parallelism directly, 'cos I wanted to see what else blew up as a result. =)

cc @vivek jamesdumay kzantow hrmpw michaelneale for your thoughts. Again, remember this is not targeted for 1.0 so don't freak out. =)

Nesting and intermixing of stages and stage seems overly complicated but I'm not sure I have something better right now. At least with parallel the fact that is something different visually alerts you that something different is going on. With this, you have to track indentation and number of } to know what to expect.

Yeah, I get what you mean. I'm open to calling it something other than stages but not parallel since that's already a meaningful term in Scripted Pipeline.

Well, I understand the possible issue if this is basically run through the existing groovy interpreter, but I'd like to see something like:

stage('Build') {
  parallel { // this indicates running stages in parallel
    stage('Windows') {
       ...
    }
    stage('Linux') {
      ...
    }
  }
}

Or more simply, just have a rule that all stages within a stage must finish before it completes, and add a parallel flag for nested stages?

stage('Build', parallel) {
  stage('Windows') {
     ...
  }
  stage('Linux') {
    ...
  }
}

... just some thoughts on this. I'm not a big fan of huge nesting, I already feel like it's getting a bit too nested for my tastes in places. Might as well just use LISP if we wanted that!

So I am vehemently opposed to adding more arguments to stage because I'm still not happy about there being any arguments to stage. =) Not to mention that would be a pain to translate between Groovy syntax and JSON syntax. kzantow's first example is basically the one I've proposed but with a different name for the block (parallel vs stages) and, well, I kinda have that working, so my bias is definitely in that direction, modulo naming. We can technically handle parallel as the name, just as we handle stage when it's not really StageStep on the backend, I just prefer to avoid duplication of names if possible.

I think the first example from kzantow is pretty easy to grok but it does reuse parallel in a different way than in steps . If we take the original example from abayer in description we get:

pipeline {
  agent any
  
  stages {
    stage('first') {
      steps {
        echo 'first, non-parallel stage'
      }
    }

    stage('top-parallel') {
      parallel {
        stage('first-parallel') {
          steps {
            echo 'First of the parallel stages without further nesting'
            sleep 60
          }
        }
        stage('second-parallel') {
          parallel {
            stage('first-nested-parallel') {
              steps {
                 echo 'the first of the nested parallel stages'
                 sleep 30
              }
           }
           stage('second-nested-parallel') {
              steps {
                 echo 'the second of the nested parallel stages'
                 sleep 30
              }
           }
        }
     }
  }
}

Worth mentioning that my indentation sucked. =)