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

Recognize test results from com.github.searls:jasmine-maven-plugin

    Details

    • Similar Issues:

      Description

      jasmine-maven-plugin plugin is capable of outputting surefire/junit style reports: http://searls.github.com/jasmine-maven-plugin/

      While Jenkins will recognize jasmine-maven-plugin test results in a free-style(/freestyle) project, in a Maven project the results do not show. Free-style is nice, but then full Maven project functionality is not available, such as release and other goals.

      See jasmine-maven-plugin author searls comment here, quoted below:
      https://github.com/searls/jasmine-maven-plugin/issues/9

      "JUnit XML reports can only be specified by the user on freestyle projects. To get a maven2 project to see Jasmine's XML reports, SurefireArchiver would need to be updated to include the jasmine-maven-plugin's GAV."

      This issue is similar to JENKINS-11353. I expect it could be resolved, as searls suggests, in a similar manner. Looks like hudson.maven.reporters.SurefireArchiver would need to include registration for jasmine-maven-plugin.

        Attachments

          Issue Links

            Activity

            Hide
            willcainsvg Will Cain added a comment -

            Example jasmine plugin configuration:

            <plugin>
              <groupId>com.github.searls</groupId>
              <artifactId>jasmine-maven-plugin</artifactId>
              <version>1.1.0</version>
              <executions>
                <execution>
                  <goals>
                    <goal>test</goal>
                  </goals>
                </execution>
              </executions>
              <configuration>
                <jsSrcDir>${project.basedir}/src/main</jsSrcDir>
                <jsTestSrcDir>${project.basedir}/src/test</jsTestSrcDir>
                <junitXmlReportFileName>
                ../surefire-reports/TEST-jasmine.xml</junitXmlReportFileName>
                <sourceIncludes>
                  <include>js/my.js</include>
                </sourceIncludes>
              </configuration>
            </plugin>
            
            Show
            willcainsvg Will Cain added a comment - Example jasmine plugin configuration: <plugin> <groupId>com.github.searls</groupId> <artifactId>jasmine-maven-plugin</artifactId> <version>1.1.0</version> <executions> <execution> <goals> <goal>test</goal> </goals> </execution> </executions> <configuration> <jsSrcDir>${project.basedir}/src/main</jsSrcDir> <jsTestSrcDir>${project.basedir}/src/test</jsTestSrcDir> <junitXmlReportFileName> ../surefire-reports/TEST-jasmine.xml</junitXmlReportFileName> <sourceIncludes> <include>js/my.js</include> </sourceIncludes> </configuration> </plugin>
            Hide
            willcainsvg Will Cain added a comment - - edited

            Here's a work-around I discovered while attempting to make the SurefireArchiver change. Turns out Jenkins will already notice jasmine-maven-plugin results when run through surefire-maven-plugin. You just have to tell surefire-maven-plugin explicitly to run test goal, preferably during package phase.

            For example:

                  <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <version>2.12</version>
                    <executions>
                      <execution>
                        <goals>
                          <goal>test</goal>
                        </goals>
                        <!-- ensures surefire runs after jasmine: -->
                        <phase>package</phase>
                      </execution>
                    </executions>
                  </plugin>
            

            My testing demonstrate this indeed works. For me this greatly reduces the need for a Jenkins change.

            Show
            willcainsvg Will Cain added a comment - - edited Here's a work-around I discovered while attempting to make the SurefireArchiver change. Turns out Jenkins will already notice jasmine-maven-plugin results when run through surefire-maven-plugin. You just have to tell surefire-maven-plugin explicitly to run test goal, preferably during package phase. For example: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.12</version> <executions> <execution> <goals> <goal>test</goal> </goals> <!-- ensures surefire runs after jasmine: --> <phase> package </phase> </execution> </executions> </plugin> My testing demonstrate this indeed works. For me this greatly reduces the need for a Jenkins change.
            Hide
            davispw Peter Davis added a comment - - edited

            I'd also love to see this fixed. In the meantime, I adapted Will Cain's workaround. I don't really like the JUnits to run during the "package" phase.

            Assuming there is a maven-surefire-plugin declared in your parent pom:

            <plugin>
            	<groupId>com.github.searls</groupId>
            	<artifactId>jasmine-maven-plugin</artifactId>
            	<version>1.2.0.0</version>
            ...
            </plugin>
            <plugin>
            	<artifactId>maven-surefire-plugin</artifactId>
            	<executions>
            		<execution>
            			<!-- Ensure surefire runs after Jasmine.
            			   - https://issues.jenkins-ci.org/browse/JENKINS-13188
            			   - Maven plugins are run in the order specified in pom.xml, with inherited plugins first.
            			   - So we must redefine the "test" goal's execution to be after Jasmine. -->
            			<id>surefire-test</id>
            			<phase>test</phase>
            			<goals>
            				<goal>test</goal>
            			</goals>
            			<configuration>
            				<skipTests>${skipTests}</skipTests>
            			</configuration>
            		</execution>
            	</executions>
            	<configuration>
            		<!-- Disable the default maven-surefire-plugin execution from parent pom. -->
            		<skipTests>true</skipTests>
            	</configuration>
            </plugin>
            

            Edit: just pointing out you can do pretty much the same thing with maven-failsafe-plugin:integration-test as maven-surefire-plugin:test if needed.

            Show
            davispw Peter Davis added a comment - - edited I'd also love to see this fixed. In the meantime, I adapted Will Cain's workaround. I don't really like the JUnits to run during the "package" phase. Assuming there is a maven-surefire-plugin declared in your parent pom: <plugin> <groupId> com.github.searls </groupId> <artifactId> jasmine-maven-plugin </artifactId> <version> 1.2.0.0 </version> ... </plugin> <plugin> <artifactId> maven-surefire-plugin </artifactId> <executions> <execution> <!-- Ensure surefire runs after Jasmine. - https://issues.jenkins-ci.org/browse/JENKINS-13188 - Maven plugins are run in the order specified in pom.xml, with inherited plugins first. - So we must redefine the "test" goal's execution to be after Jasmine. --> <id> surefire-test </id> <phase> test </phase> <goals> <goal> test </goal> </goals> <configuration> <skipTests> ${skipTests} </skipTests> </configuration> </execution> </executions> <configuration> <!-- Disable the default maven-surefire-plugin execution from parent pom. --> <skipTests> true </skipTests> </configuration> </plugin> Edit: just pointing out you can do pretty much the same thing with maven-failsafe-plugin:integration-test as maven-surefire-plugin:test if needed.
            Hide
            akbertram Alexander Bertram added a comment - - edited

            This is a clever hack, will!

            But it would still be great to fix so this so that any maven plugin that produces junit-compatible xml will be consumed without having to muck around with plugin order.

            Is it possible for SurefireArchiver to search for tests after each module has finished? I am trying to get the renjin-maven-plugin:test goal working on Jenkins, which produces junit xml files from R-language tests, and it would be great to have it work out of the box.

            Show
            akbertram Alexander Bertram added a comment - - edited This is a clever hack, will! But it would still be great to fix so this so that any maven plugin that produces junit-compatible xml will be consumed without having to muck around with plugin order. Is it possible for SurefireArchiver to search for tests after each module has finished? I am trying to get the renjin-maven-plugin:test goal working on Jenkins, which produces junit xml files from R-language tests, and it would be great to have it work out of the box.
            Hide
            adrianp Adrian Price added a comment -

            See linked JENKINS-31258 for a generalised solution that should work for any unknown test-capable Maven plug-in.

            Show
            adrianp Adrian Price added a comment - See linked JENKINS-31258 for a generalised solution that should work for any unknown test-capable Maven plug-in.
            Hide
            burnyburnsson Andreas added a comment - - edited

            Can anybody confirm the solution posted by Adrian Price (-JENKINS-31258)- works?

            I've tried this, but still the Jasmine report is not picked up by Jenkins in the test-reports.

            <jenkins.jasmine-maven-plugin.reportsDirectory>${project.build.directory}${file.separator}jasmine</jenkins.jasmine-maven-plugin.reportsDirectory>

             

            However, the workaround posted by Peter Davis worked for me.

            Show
            burnyburnsson Andreas added a comment - - edited Can anybody confirm the solution posted by Adrian Price  (- JENKINS-31258 )- works? I've tried this, but still the Jasmine report is not picked up by Jenkins in the test-reports. <jenkins.jasmine-maven-plugin.reportsDirectory>${project.build.directory}${file.separator}jasmine</jenkins.jasmine-maven-plugin.reportsDirectory>   However, the workaround posted by Peter Davis worked for me.
            Hide
            adrianp Adrian Price added a comment -

            @Andreas (Boehme) my solution (JENKINS-31258 option 3) targets JUnit-result-producing Maven plug-ins that are unknown to Jenkins Maven plug-in. By contrast, the jasmine-maven-plugin you mention is known to Jenkins Maven plug-in as a JUnit-result-producing plug-in and by rights ought to work OOTB. However, having looked at the source code, the JENKINS-31258 approach probably would work for all JUnit-result-producing plug-ins both known and unknown.

            Just to be clear: as per documentation, the property name format is jenkins.<plugin-execution-id>.reportsDirectory, where <plugin-execution-id> is the <id> of the <execution> of the <plugin> whose JUnit output you wish to include. It looks as if you might be using the plug-in's artifact id instead of its execution id, which won't work.

            Show
            adrianp Adrian Price added a comment - @Andreas (Boehme) my solution ( JENKINS-31258 option 3) targets JUnit-result-producing Maven plug-ins that are unknown to Jenkins Maven plug-in. By contrast, the jasmine-maven-plugin you mention is known to Jenkins Maven plug-in as a JUnit-result-producing plug-in and by rights ought to work OOTB. However, having looked at the source code, the JENKINS-31258 approach probably would work for all JUnit-result-producing plug-ins both known and unknown. Just to be clear: as per documentation , the property name format is jenkins.<plugin-execution-id>.reportsDirectory, where <plugin-execution-id> is the <id> of the <execution> of the <plugin> whose JUnit output you wish to include. It looks as if you might be using the plug-in's artifact id instead of its execution id, which won't work.

              People

              • Assignee:
                Unassigned
                Reporter:
                willcainsvg Will Cain
              • Votes:
                2 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: