Details
-
Type:
Improvement
-
Status: Closed (View Workflow)
-
Priority:
Minor
-
Resolution: Duplicate
-
Component/s: pipeline-model-definition-plugin
-
Labels:
-
Environment:We track Jenkins LTS approx 4 weeks behind.
-
Similar Issues:
Description
The post.always action should be the last action run in a stage or pipeline. At present it will run BEFORE the post.success, aborted, and failure actions which doesn't make much sense.
Example:
I want to clean the workspace at the end of a stage regardless of status, and I want to archive some files on success. The logical way to achieve this is to clean the workspace in the post.always and archive the files on post.success. This is not possible in the current plugin.
I know there are ways to get round this 'feature' but they are not exactly intuitive.
Attached a simple pipeline to demonstrate the issue.
Attachments
Issue Links
- duplicates
-
-
- Closed
-
Activity
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-Kees 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.
Staffan Forsell
added a comment - Johan-Kees 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.
Johan-Kees 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.