Hi, Alexey!
>> If we can use multi JVM test with
>> different classpaths I will use them - such approach is more convenient
>> from TC point of view.
There is not such ability at the moment, you are only able to specify
additional JVM arguments in
'GridAbstractTest#additionalRemoteJvmArgs'.
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
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
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:
gnite sub-projects as well.
>
> пт, 1 мар. 2019 г. в 19:04, Алексей Платонов :
> >
> > Hello, Igniters!
> > I would like to create several tests for ML algorithms using binary
> builds.
> > These tests should work in this way:
> > 1) Get last master (or user
e several tests for ML algorithms using binary builds.
> These tests should work in this way:
> 1) Get last master (or user-defined branch) from git repository;
> 2) Build Ignite with a release profile and create binary build;
> 3) Run several Ignite instances from binary bui
Hello, Igniters!
I would like to create several tests for ML algorithms using binary builds.
These tests should work in this way:
1) Get last master (or user-defined branch) from git repository;
2) Build Ignite with a release profile and create binary build;
3) Run several Ignite instances from
