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

Pipeline Model Definition Post Action Order

    XMLWordPrintable

    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

            rayalexander Ray Alexander created issue -
            rayalexander Ray Alexander made changes -
            Field Original Value New Value
            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 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 archived 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.

             
            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.

             
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - Lemme think about this. I swear there were reasons I had always before everything else, but they may have been stupid. =)
            Hide
            lsglick Logan Glickfield added a comment -

            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?

            Show
            lsglick Logan Glickfield added a comment - 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?
            Hide
            johan_vliek Johan-Kees Vliek added a comment -

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

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

            Johan-Kees 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

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

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

            Show
            johan_vliek Johan-Kees Vliek added a comment - Gotcha. Makes sense. For this, it won't matter what the order of the actions is, right?
            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".
            abayer Andrew Bayer made changes -
            Link This issue duplicates JENKINS-41519 [ JENKINS-41519 ]
            abayer Andrew Bayer made changes -
            Resolution Duplicate [ 3 ]
            Status Open [ 1 ] Resolved [ 5 ]
            Hide
            bitwiseman Liam Newman added a comment -

            Bulk closing resolved issues.

            Show
            bitwiseman Liam Newman added a comment - Bulk closing resolved issues.
            bitwiseman Liam Newman made changes -
            Status Resolved [ 5 ] Closed [ 6 ]

              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: