Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
RFC: JENKINS-41334: Parallel stage execution
  • Loading branch information
abayer committed Feb 27, 2017
1 parent b20a621 commit 27e41dd
Showing 1 changed file with 86 additions and 0 deletions.
86 changes: 86 additions & 0 deletions rfc/JENKINS-41334-parallel-stage-execution.md
@@ -0,0 +1,86 @@
## RFC: [JENKINS-41334](https://issues.jenkins-ci.org/browse/JENKINS-41334) - Parallel stage execution

* Author: Andrew Bayer
* Created Date: February 27, 2017
* Approved Date: n/a
* JIRA: [JENKINS-41334](https://issues.jenkins-ci.org/browse/JENKINS-41334)
* Status: Draft

### Problem Statement

The `parallel` step does not fit smoothly into Declarative. It doesn't
allow for parallel stage execution, it doesn't utilize the `agent`
definition, etc. There needs to be the ability to run `stage`s in
parallel, with the full power of the Declarative syntax enabled -
i.e., `agent`, `post`, `when`, etc.

### Syntax

#### Proposed example

```groovy
stage('foo') {
parallel {
stage('first') {
steps {
echo "First branch"
}
}
stage('second') {
steps {
echo "Second branch"
}
}
}
}
```

#### Details

* A `stage` has to contain one and only one of `steps` or
`parallel`. They cannot be combined in the same `stage`.
* `stage` configuration can be done on both a `stage` containing
`parallel`, or `stage`s within `parallel`, i.e., `agent`, `when`,
`post`, etc.
* `agent`, `environment`, and `tools` specified on the "parent"
`stage` will apply to child `stage`s in the same way that top-level
configuration applies to `stage`s currently.
* Naming of `parallel` is up for debate.

### Runtime Implementation

There are two options for runtime. Which one we go with depends on
Blue Ocean visualization decisions. The first option is to simply nest
stage executions, while the second option is to not actually use the
`stage` step for the nested `stage`s and instead utilize the `stage`
names as the names of parallel branches.

These two options each have their pros and cons. A pro in one option
tends to lead to a con in the other option.

#### Pro/Con

* Stage status/metadata (i.e., skipped due to failure/`when`) would
not work in the parallel branches approach, since that relies on
adding metadata to the stage representation in the flow graph. This
could cause issues in visualization.
* Nested stages would allow for identical code paths for execution of
a stage regardless of whether the stage is a nested stage or not, so
the code would be simpler than for parallel branches.
* Blue Ocean supports visualization of parallel branches already, so
less work would be needed there than for nested stages.
* Neither approach will visualize deeper levels of parallelization in
Blue Ocean as currently designed/implemented.

#### Proposed Approach

Nested stages is a superior approach, even though it requires design
and implementation work in Blue Ocean for proper visualization. Given
that the nested stages will still be executed in named parallel
branches, Blue Ocean as it is now will continue to visualize nested
stages as if they were just parallel branches, albeit without the
stage status metadata.

Given the benefits to the nested stages over parallel branches in
terms of implementation and metadata, it seems preferrable to go with
the nested stages implementation.

0 comments on commit 27e41dd

Please sign in to comment.