Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-46378

Pipeline Model Definition Post Action Order

    Details

    • 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

            Activity

            Hide
            fkykko Staffan Forsell added a comment -

            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.

            Show
            fkykko Staffan Forsell added a comment - 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.
            Hide
            johan_vliek Johan-Kees Vliek added a comment -

            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...

            Show
            johan_vliek Johan-Kees Vliek added a comment - 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...
            Hide
            fkykko 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.

            Show
            fkykko 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.
            Hide
            johan_vliek Johan-Kees Vliek added a comment -

            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".

            Show
            johan_vliek Johan-Kees Vliek added a comment - 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".
            Hide
            bitwiseman Liam Newman added a comment -

            Bulk closing resolved issues.

            Show
            bitwiseman Liam Newman added a comment - Bulk closing resolved issues.

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                rayalexander Ray Alexander
              • Votes:
                2 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: