Lemme think about this. I swear there were reasons I had always before everything else, but they may have been stupid. =)

Not sure how this works currently, but I could imagine a junit step in always that you'd then want to either pass/fail the build and have corresponding success/failure actions called?

Don't think unit tests should be done as part of post functions. These are logically part of the build, and should be a stage in the pipeline build (imho).

We ran into the same issue as the reporter of this ticket. In failure and success actions we set some variables (BUILD_RESULT), which is used in the "always" action. Since "always" runs first, this is not working. As a result of this, we need to move the code from "always" to "failure" and "success".

johan_vliek The junit step does not run the tests, it just records the results. Sp logically they should be in the always block of the stage that run the unit tests

Gotcha. Makes sense. For this, it won't matter what the order of the actions is, right?

johan_vliek Actually it does. If you have junit in an always block this might change the status of the build.
If the always block is first then logically any failure/unstable would be executed if test fails/files are missing. But if the junit block is last in an already failing build, should it then rerun a failure block that has already been executed? These kind of scenarios needs to be thought through if the post order is changed.

In that case, why not make it part of the pipeline? Why would you want this to be part of the aways action? It can just as easy be in the same pipeline step as the actual junit tests, or in one right after. I don't see what benefit you'd get by using always in that case.

How we use it, is that anything that potentially breaks the build (thus, which is part of the build), is in the pipeline. The post functions are used to communicate the results (in our case to JIRA). I guess use-cases differ...

johan_vliek The problem with having junit in the same stage (and not the * post block)  is  that  the *step before junit (presumably sh './gradlew test') will fail with exit code != 0 if test fails and you still want to get the test results. Yes, there might be ways around this, but they're not as clean.

Anyway, this is not really discussion forum, let's just agress that the orginal use is a valid use-case and there are probably more ones that we have not thought of.

Defining the ordering in https://jenkins.io/doc/book/pipeline/syntax/ would probably be good and also what would happen if the result is changed by a post block.

Agreed. 

If always stays as the first action, it might be worth considering adding one more that is guaranteed to run after all actions have been processed. Maybe something like "finally".

Bulk closing resolved issues.