Maven
  1. Maven
  2. MNG-2142

Forcing execution of the post-integration-test phase

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 2.0.3
    • Fix Version/s: None
    • Component/s: Integration Tests
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      The post-integration-test phase needs to always be called even in case of tests failures in the integration-test phase.

      For example when using Cargo the container may be left running if the post-integration-test phase is not called...

        Activity

        Hide
        Brett Porter added a comment -

        This flies in the face of the current lifecycle design. The only way I see this is being feasible is if we do use the pre/post automated phase wrappers and make their semantics to behave in this way.

        The alternative is to not fail from the integration-test goal, but set a property, then fail from the post- phase after everything is done. Sounds hacky though.

        Show
        Brett Porter added a comment - This flies in the face of the current lifecycle design. The only way I see this is being feasible is if we do use the pre/post automated phase wrappers and make their semantics to behave in this way. The alternative is to not fail from the integration-test goal, but set a property, then fail from the post- phase after everything is done. Sounds hacky though.
        Hide
        Andrew Williams added a comment -

        As I understand it the pre- and post- integration-test phases are for controlling the integration environment, so I think it is vital that the post is called even on failure.

        Is there a semantic already that assumes a post- running means success? perhaps pre- and post- whatever should always run for the phase then the lifecycle is defined as a list of phases (exclusing pre- and post-) each of which will invoke a pre- before and a post- after. I believe this would fix another bug I read, though I cannot remember which.

        Show
        Andrew Williams added a comment - As I understand it the pre- and post- integration-test phases are for controlling the integration environment, so I think it is vital that the post is called even on failure. Is there a semantic already that assumes a post- running means success? perhaps pre- and post- whatever should always run for the phase then the lifecycle is defined as a list of phases (exclusing pre- and post-) each of which will invoke a pre- before and a post- after. I believe this would fix another bug I read, though I cannot remember which.
        Hide
        Federico Fernández added a comment - - edited

        It's possible to configure the Surefire plugin to continue a build even if it encounters a failure. For example, i have:

        <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
        <skip>true</skip>
        </configuration>
        <executions>
        <execution>
        <id>surefire-ut</id>
        <phase>test</phase>
        <goals>
        <goal>test</goal>
        </goals>
        <configuration>
        <skip>false</skip>
        <excludes>
        <exclude>**/*ITest.java</exclude>
        </excludes>
        </configuration>
        </execution>
        <execution>
        <id>surefire-it</id>
        <phase>integration-test</phase>
        <goals>
        <goal>test</goal>
        </goals>
        <configuration>
        <skip>false</skip>
        <includes>
        <include>**/*ITest.java</include>
        </includes>
        <testFailureIgnore>true</testFailureIgnore>
        </configuration>
        </execution>
        </executions>
        </plugin>

        My Unit Tests ends with Test.java and my Integration Tests ends with ITest.java. With <testFailureIgnore>, when Maven encounters a error in a Integration Test it continue the execution, stopping the server. Hope it helps

        Show
        Federico Fernández added a comment - - edited It's possible to configure the Surefire plugin to continue a build even if it encounters a failure. For example, i have: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <skip>true</skip> </configuration> <executions> <execution> <id>surefire-ut</id> <phase>test</phase> <goals> <goal>test</goal> </goals> <configuration> <skip>false</skip> <excludes> <exclude>**/*ITest.java</exclude> </excludes> </configuration> </execution> <execution> <id>surefire-it</id> <phase>integration-test</phase> <goals> <goal>test</goal> </goals> <configuration> <skip>false</skip> <includes> <include>**/*ITest.java</include> </includes> <testFailureIgnore>true</testFailureIgnore> </configuration> </execution> </executions> </plugin> My Unit Tests ends with Test.java and my Integration Tests ends with ITest.java. With <testFailureIgnore>, when Maven encounters a error in a Integration Test it continue the execution, stopping the server. Hope it helps
        Hide
        Gregor Heine added a comment -

        Wow, this is a pretty bad flaw. What else is the purpose of a post-integration-test phase if not to do clean up after the integration-test phase, regardless whether the tests passed or not (like e.g. shutting down a cargo container). Any chance this can get fixed before 3.x?

        Show
        Gregor Heine added a comment - Wow, this is a pretty bad flaw. What else is the purpose of a post-integration-test phase if not to do clean up after the integration-test phase, regardless whether the tests passed or not (like e.g. shutting down a cargo container). Any chance this can get fixed before 3.x?
        Hide
        Paul Benedict added a comment -

        Can a flag be set so plugins can determine whether the post-process phase is being invoked after success or failure?

        Show
        Paul Benedict added a comment - Can a flag be set so plugins can determine whether the post-process phase is being invoked after success or failure?
        Hide
        Christopher Barrow added a comment - - edited

        We are are hitting this too. Definitely a fix asap would be much appreciated. The workaround
        of setting testFailureIgnore to true causes the whole build to appear to succeed which is not generally what one wants when there are test failures. Paul's idea of a flag would be a helpful workaround.

        Show
        Christopher Barrow added a comment - - edited We are are hitting this too. Definitely a fix asap would be much appreciated. The workaround of setting testFailureIgnore to true causes the whole build to appear to succeed which is not generally what one wants when there are test failures. Paul's idea of a flag would be a helpful workaround.
        Hide
        Christopher Barrow added a comment -

        Actually there is a good solution which is to use the failsafe plug-in. This is designed for integration tests and handles this case very well. The test failures are discovered in the verify phase so the post-integration-test phase is always executed. So I would suggest it's not worth fixing this bug.

        Show
        Christopher Barrow added a comment - Actually there is a good solution which is to use the failsafe plug-in. This is designed for integration tests and handles this case very well. The test failures are discovered in the verify phase so the post-integration-test phase is always executed. So I would suggest it's not worth fixing this bug.
        Show
        Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
        Hide
        Jason van Zyl added a comment -

        Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

        Show
        Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          People

          • Assignee:
            Unassigned
            Reporter:
            Vincent Massol
          • Votes:
            16 Vote for this issue
            Watchers:
            14 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: