Ivan, Thank for your answer. I want to use binary builds explicitly because they don't share jars of client code. If we can use multi JVM test with different classpaths I will use them - such approach is more convenient from TC point of view.
P.S. I use Docker in my prototype just because it is easy for me and for test cluster management - I can create docker-image with all configs and scripts and run Ignite cluster in a separate network. On Tue, Mar 5, 2019 at 12:28 PM Павлухин Иван <vololo...@gmail.com> wrote: > Alexey, > > If problems arise in environments different from one where usual > Ignite tests run then definitely it is a good idea to cover it. And > testing other build kinds and in other environments is a good idea as > well. But a particular problem with serialization and peer class > loading is not clear for me. Why binary builds and Docker are needed > there? Why multi JVM tests from Ignite testing framework cannot reveal > mentioned problems? > > Ideally I think we should aggregate all failure reporting in common > place. And for me TC bot is the best choice. Consequently it should be > TeamCity most likely. > > But all in all I think we can give it a try according to you proposal > and see how the things will go. > > вт, 5 мар. 2019 г. в 11:09, dmitrievanthony <dmitrievanth...@gmail.com>: > > > > Hi Alexey, > > > > I think it's a great idea. Travis + Docker is a very good and cheap > > solution, so we could start with it. Regards the statistics, Travis > allows > > to check a last build status using a badge, so it also shouldn't be a > > problem. > > > > Best regards, > > Anton Dmitriev. > > > > > > > > -- > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > -- > Best regards, > Ivan Pavlukhin >
