Anthony, thank you for providing the info. It is straightforward while developing.
Some of us think we should run all tests (several hours according to Dan) and there are good reasons to do so. Roman, if you know the answer, please let us know; is it OK to occupy jenkins slaves for several hours on each test-patch on builds.a.o? Is there any guideline we should follow in order to use builds.a.o? On Tue, Jun 16, 2015 at 2:31 PM, Anthony Baker <[email protected]> wrote: > What I’m speaking of is a development process where you > > 1) write some code > 2) run some relevant tests > 3) repeat until done > > You can do that with gradle as follows (just as examples): > > gradle :gemfire-core:test -Dtest.single=ArrayUtilsJUnitTest > gradle :gemfire-core:test -Dtest.single=com/gemstone/gemfire/internal/util/ > gradle :gemfire-core:integrationTest > -DintegrationTest.single=DistributedSystemFactoryIntegrationJUnitTest > > > An optimized CI subset (maximum coverage / minimum runtime) could be > created but I think it would be better to first get all of the tests pulled > into the project and make sure we’re getting consistent, stable results. > > Anthony > > > On Jun 16, 2015, at 1:57 PM, jun aoki <[email protected]> wrote: > > > > I've made a root ticket and a few sub tasks > > https://issues.apache.org/jira/browse/GEODE-59 > > for the CI work. > > > > Anthony, I'm also interested in how to execute a subset of tests. Let me > > know! > > > > On Mon, Jun 15, 2015 at 10:25 PM, Roman Shaposhnik <[email protected] > > > > wrote: > > > >> On Mon, Jun 15, 2015 at 7:04 PM, Anthony Baker <[email protected]> > wrote: > >>> I typically use a smaller subset of tests while iterating on a change. > >>> Once I believe it is solid I’ll run the full set before I commit. > >> > >> Is there a gradle task to run that subset? > >> > >> Thanks, > >> Roman. > >> > > > > > > > > -- > > -jun > > -- -jun
