> On May 11, 2016, 11:22 p.m., Kirk Lund wrote:
> > Need to find a solution that does not involve a Suite.
> > 
> > CommandOverHttpTests will cause all of the Commands dunit tests to be 
> > executed twice but the second time each runs will override the results xml 
> > for the first time. This causes only one to be recorded in Jenkins history.
> > 
> > For example, if the first run fails, but the second one passes, then the 
> > result of the 1st run is lost and gradle/jenkins/etc will report no 
> > failures. 
> > 
> > We really only have two useable options: 1) use some form of params runner 
> > because those are junit runners that result in two different results xmls 
> > being written out for each param (everything that reports results or 
> > records history is reading these xmls), 2) subclass each of these tests 
> > with the subclasses containing only the @ClassRule overriding the system 
> > property. #2 is ugly to us as developers but is actually cleaner than #1 in 
> > the jenkins results.

used a custom SuiteRunner to solve this problem. As seen here: 
https://jenkins.eng.pivotal.io/jenkins/job/GEM-patch-build/234/testReport/unit/junit/com.gemstone.gemfire.management.internal.cli.commands/FunctionCommandsDUnitTest/.
 It's appending the suite class name to the method name to avoid overriding the 
result.


> On May 11, 2016, 11:22 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/GfshCommandsSecurityTest.java,
> >  line 43
> > <https://reviews.apache.org/r/47187/diff/2/?file=1379907#file1379907line43>
> >
> >     We should try to change these to non-static.

the ports are used in a static classRule, so looks like it needs to stay static


- Jinmei


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/47187/#review132784
-----------------------------------------------------------


On May 11, 2016, 8:09 p.m., Jinmei Liao wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47187/
> -----------------------------------------------------------
> 
> (Updated May 11, 2016, 8:09 p.m.)
> 
> 
> Review request for geode, Jens Deppe and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> -------
> 
> GEODE-17: make sure commands tests are run in useHttp mode.
> 
> updated the trusted.keystore to use the supported algorithm
> 
> 
> Diffs
> -----
> 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/management/internal/configuration/SharedConfigurationEndToEndDUnitTest.java
>  caee9eaeed6c5cda363cb7352d6bd18ea0867d3f 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/security/shiro/ShiroPrincipal.java
>  8413ebba49ae588730fb709485a1cab4518ff639 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/CliCommandTestBase.java
>  0486c5ace90316f9afedb61e78ca59756f630058 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/ConnectCommandWithHttpAndSSLDUnitTest.java
>  2e0897d0877b9673c05821bcf5b0b2fc1aeb55f0 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/SharedConfigurationCommandsDUnitTest.java
>  781ed982a855d0d0cd31c1ebcc352fe46871417b 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/GfshCommandsSecurityTest.java
>  d96c96cabc383ce03f641abfbd98b803182c24f2 
>   geode-core/src/test/resources/ssl/trusted.keystore 
> 6057e3ca171a85ad2b85c7590575cee12cf5b59a 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/management/internal/configuration/ClusterConfigurationDUnitTest.java
>  62bb793cc91f5a7a68daba133e77e800855f0e4d 
>   geode-web/build.gradle 5bd1d8949c1b1379ddd6a1bd8ab2751ce73a79fd 
>   
> geode-web/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/CommandOverHttpTests.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/47187/diff/
> 
> 
> Testing
> -------
> 
> running precheckin ....
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Reply via email to