-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
I'd like to create two stages, where if one runs the other doesn't - effectively and `if-else`.
Right now I'd have to do something like this:
stages { stage ('Full Build') { when { expression { return params.FORCE_FULL_BUILD } } } stage ('Incremental Build') { when { expression { return !params.FORCE_FULL_BUILD } } } }
For simple expressions, that's no problem. For complex expressions it gets tiresome.
The `when {}` block needs a way to indicate `else`. This could be done (when combined with a logical `not` condition) by have a `stage` condition. Like so:
stages { stage ('Full Build') { when { expression { return params.FORCE_FULL_BUILD } } } stage ('Incremental Build') { when { not { stage 'Full Build' } } } }
This would also allow for stages to depend on previous stages in a clear fashion. For example:
stages { stage ('Full Build') { when { expression { return params.FORCE_FULL_BUILD } } } stage ('Incremental Build') { when { not { stage 'Full Build' } } } stage ('Full Tests') { when { stage 'Full Build' } } } stage ('Incremental Tests') { when { stage 'Incremental Build' } } } }
- relates to
-
JENKINS-41185 [Declarative Pipeline] Stage "when" should have logical operator steps (and, or, not, all, any)
-
- Closed
-
- links to
I don't like this syntax formatting.
When I see this :
I read it as when this Stage is not "Full Build". My first reaction is that is always true.
If we want to say it is dependent in someway then we need to make that relationship explicit. When stage "Full Build" is not what? Not skipped, not run, not stable? That isn't clear.
Right now the use case described is easily done as shown. To me that is much more clear than the alternative. We can explore having some stage conditions but they need to be clear.
Maybe something like:
Or
Or