| Please note, right now I'm testing a workaround that's based on the code in pipeline-model-extensions/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/model/BuildCondition.java. That's the code that seems to return a counter-intuitive result that mixes some stage-specific things with non-stage-specific things. I can create a global pipeline library method that basically pulls out the 3 components that BuildCondition uses, errorResult, execResult, and prevResult, and inspect and use them directly:
@NonCPS
Map<String,String> getStageConditionResults () {
Map<String,String> results = [:]
String stageName = env.STAGE_NAME
WorkflowRun run = currentBuild.getRawBuild()
Result errorResult = Result.SUCCESS;
List<FlowNode> startAndEnd = CommonUtils.findPossiblyUnfinishedEndNodeForCurrentStage(stageName, run.getExecution());
if (startAndEnd.size() == 2 && startAndEnd.get(0) != null && startAndEnd.get(1) != null) {
DepthFirstScanner scanner = new DepthFirstScanner();
if (scanner.setup(startAndEnd.get(1), Collections.singletonList(startAndEnd.get(0)))) {
WarningAction warningAction = StreamSupport.stream(scanner.spliterator(), false)
.map({node -> node.getPersistentAction(WarningAction.class)})
.filter(Objects.&nonNull)
.max(Comparator.comparing({warning -> warning.getResult().ordinal}))
.orElse(null);
if (warningAction != null) {
errorResult = warningAction.getResult();
}
}
}
Result execResult = run.getExecution().getResult()
Result prevResult = run.getResult();
if (prevResult == null) {
prevResult = Result.SUCCESS;
}
if (execResult == null) {
execResult = Result.SUCCESS;
}
results['errorResult'] = errorResult.toString()
results['execResult'] = execResult.toString()
results['prevResult'] = prevResult.toString()
return results
}
What I notice is that unstable stages have UNSTABLE errorResult and successful stages have SUCCESS errorResult. But once one stage has UNSTABLE prevResult, all subsequent stages have UNSTABLE prevResult. It looks like in the BuildCondition code, that UNSTABLE prevResult will trump the SUCCESS errorResult and return UNSTABLE as the overall Result for a successful stage, firing stage post conditions like "unsuccessful". Really what would be good is a pair of stage post conditions like success/unsuccessful that ignores the UNSTABLE prevResult. In any case, I'm going to try using this pipeline library method in our stage post sections to detect when a stage is unstable and requires notifications. Is there any chance similar logic could be implemented by the existing post conditions, or added as new post conditions?
|
