Yeap!
I'll start implementing it next week.
I think I'll create new jobs and when everything is OK — will switch settings
in template to new chain.
It will take some time to do everything right though.
> On 5 Mar 2021, at 09:28, Maksim Timonin wrote:
>
> Hi, Petr!
>
> I've created a ticket
Hi, Petr!
I've created a ticket [1] for that and assigned it on you. Could you please
catch it when you have time?
[1] https://issues.apache.org/jira/browse/IGNITE-14283
On Wed, Mar 3, 2021 at 11:06 PM Maxim Muzafarov wrote:
> Max,
>
> > There is an overhead for running git + mvn test twice,
Max,
> There is an overhead for running git + mvn test twice, but it is a cost for
> the flexibility.
Yes, I mean this issue. I have no objections, the build queue seems to
be empty most of the time.
On Wed, 3 Mar 2021 at 21:01, Max Timonin wrote:
>
> Yes, they can be performed as parallel,
Yes, they can be performed as parallel, as doesn't depend on each other.
There is an overhead for running git + mvn test twice, but it is a cost for
the flexibility.
On Wed, Mar 3, 2021 at 8:55 PM Max Timonin wrote:
> I mean that any TC job with tests depends on both [Build], [Sanity
> Checks].
I mean that any TC job with tests depends on both [Build], [Sanity Checks].
No tests run if any of those jobs failed.
[Build] prepares ignite.zip for distribution between TC agents (mvn
install).
[Sanity Checks] checks that code is correct in terms of our static checks
(mvn test).
Indeed it can
Maxim,
Can you clarify what means '[Sanity Checks] runs in parallel with
[Build]'? AFAIK the checks need the build results to run themselves.
On Wed, 3 Mar 2021 at 18:48, Max Timonin wrote:
>
> Discussed with Petr privately. Proposal is:
>
> 1. The [Build] job runs without any checks.
> 2.
Discussed with Petr privately. Proposal is:
1. The [Build] job runs without any checks.
2. There will be a new job [Sanity Checks], that runs all checks -
checkstyle, licenses, javadoc, check-suites.
3. [Sanity Checks] runs in parallel with [Build].
4. All TC jobs with tests depend on a result of
Hi Petr! My proposal is:
1. Create a parameter in [Build] TC suite - MAVEN_CHECKS, default value is
"-Plicenses,checkstyle,check-licenses,check-test-suites".
2. Use it in a command along with MAVEN_MODULES_STRING.
-U -Pall-java,all-scala,scala,lgpl,examples %MAVEN_CHECKS%
%MAVEN_MODULES_STRING%
If profile can handle this — its ok.
For choosing build type — we can introduce select, that will choose between -p
and -DskipTests=true (defaulting to profile).
Thus [Build] will pass either way.
Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59
Yes, it's correct that "mvn install" runs also the "mvn test" command, and
this is OK as the check-test-suites profile handles all tests
without running them. If the skipTests flag is triggered then this check is
useless. It will take only about 2 min to run "mvn test" with this profile.
Travis
I am telling that INSTALL goal for maven will trigger TEST goal for the whole
project and it cannot be prevented until the flag is specified either as
command line parameter, or in profile somehow to be inherited by other modules.
Thats why I am suggesting this as separate suite.
Regards,
Petr
Won't the absence of -DskipTests flag trigger ALL the tests for all modules?
This flag was added intentionally.
Instead, I'd put Non-Suited tests into some kind of sanity check, group all
sanity checks in single Run All, and make tests depend on it's successful pass.
Regards,
Petr Ivanov
Head
Hi, Petr!
Profile "check-test-suites" handles all tests in another way, it just
verifies that all tests are suited. No tests run then.
As I understand the [BUILD] job goal is preparing a .zip archive to
distribute it for other jobs. I think it is a valid place to put sanity
checks. If a check
Hi, all!
What do you think if we add the check in the TC [Build] job. Currently
[Build] runs also check for licences, checkstyle [1]:
mvn *install* -Pall-java,all-scala,scala,*licenses*,lgpl,examples,
*checkstyle* -DskipTests -Dmaven.javadoc.skip=true %MAVEN_MODULES_STRING%.
So let's add the
Hello again!
Of course it's 20 minutes, not 20 seconds.
Regards,
--
Ilya Kasnacheev
вт, 9 февр. 2021 г. в 16:45, Ilya Kasnacheev :
> Hello!
>
> Java part kicks in if the target not found in pom.xml. Ideally we should
> skip this build if target check-test-suites is not in pom.xml
>
> I have
Hello!
Java part kicks in if the target not found in pom.xml. Ideally we should
skip this build if target check-test-suites is not in pom.xml
I have changed its timeout to 20 second which should terminate its
progression on older builds. Maybe that would be sufficient for now.
Regards,
--
Ilya
As much as I understood — we execute internal class as plugin, where all the
magic is done.
Seems pretty solid in Maven part. Java part, unfortunately, cannot check.
Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59
> On 9 Feb 2021, at 12:32,
Hi, Ilya.
I've added Inspections to Run All.
Checkstyle is currently integrated to Build and can be deleted.
Where can I find the code for check-test-suites profile?
Regards,
Petr Ivanov
Head of IT
IT & Development Solutions | GRIDGAIN SYSTEMS
+7 (911) 945-00-59
> On 9 Feb 2021, at 12:16,
Hello Peter,
Thanks for chiming in. The code is under
https://github.com/apache/ignite/pull/8367
Regards,
--
Ilya Kasnacheev
вт, 9 февр. 2021 г. в 12:20, Petr Ivanov :
> Hi, Ilya.
>
>
> I've added Inspections to Run All.
> Checkstyle is currently integrated to Build and can be deleted.
>
>
>
Hello!
I have found one issue where it would cause tests to be run if the change
is not present in the target branch.
This includes e.g. 2.10 nightlies.
What can we do to avoid that? Is specifying -DskipTests sufficient? Any
chance that it will break the missed tests check?
Regards,
--
Ilya
Hello!
I have created a TC suite:
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MissingTests?mode=builds
+ Peter Ivanov
Can you please check if everything is alright?
BTW, it seems that Inspections [Core] is only in Run All Basic (but not in
Run All), and Check Code Style
Hi!
Yes, now it's a part of the Travis check, and there is already a first
successful build [1]. But I think it's also required to run the check on TC
too, along with jobs for checking licenses, code style, and core
inspections.
[1] https://travis-ci.com/github/apache/ignite/builds/216363067
Hello!
I have merged it to master!
I wonder what happens next. It will run as a part of travis check? Do we
also need to add it as a TC suite?
Regards,
--
Ilya Kasnacheev
ср, 3 февр. 2021 г. в 18:50, Ilya Kasnacheev :
> Hello!
>
> Code mostly looks good, I have added a minor request. I will
Hello!
Code mostly looks good, I have added a minor request. I will check how it
works and then we may commit.
+ zaleslaw@gmail.com
Can you please check whether the new ML suites make sense?
math/distances/DistancesTestSuite.java
naivebayes/NaiveBayesTestSuite.java
Would we need to add
Hi, Ilya!
I made a fix to the check. Now it aggregates info about tests and suites
from all modules and then validates it. Could you please review the PR [1]?
I tried to move some tests between modules, but unfortunately it still
looks like spaghetti. So I reverted all changes to testsuites (new
Hello!
You could try to move these tests as .java files between modules in a
separate commit. I think I could review it.
Regards,
--
Ilya Kasnacheev
пт, 25 дек. 2020 г. в 17:19, Max Timonin :
> Hi!
>
> Ilya thanks for the reply! I agree that it's a valid case when a test is
> part of
Hi!
Ilya thanks for the reply! I agree that it's a valid case when a test is
part of multiple suites in different modules. But it is definitely a bug
that the test is written in a module where it can't be run at all and aimed
to run within different modules (core tests in core that require h2). I
Hi!
>> I'm not sure that we should assume every test is only run from one test
suite. One test may be run from different test suites located in different
modules.
Agree. For example, if we introduce this limitation, zk suites will be
broken.
пт, 25 дек. 2020 г. в 14:48, Ilya Kasnacheev :
>
Hello!
Sorry for the long wait.
I'm not sure that we should assume every test is only run from one test
suite. One test may be run from different test suites located in different
modules.
I wonder if we can drop this requirement, check all the modules
transitively for used/unused tests.
Hi,
I don't think so. It looks like a bug that tests fail if one runs them
within their module (actually, what is the goal of this test?). The check
showed us this problem, there is no need to fix the check.
Currently I see two ways:
1. Find the right module for every misplaced test. There are
Hello!
I think this means that we should abandon the plan of moving tests between
suites, and that your tool has to understand the dependency graph
between modules' tests when assessing what's included and what's not.
Regards,
--
Ilya Kasnacheev
ср, 2 дек. 2020 г. в 15:56, Max Timonin :
>
Hi, Ilya!
I've checked testsuites. There is an issue. For example
*IgniteBinaryCacheQueryTestSuite* suite is now in 2 modules: ignite-core,
ignite-indexing. On TeamCity it runs by "Query 1" suite. Simplified maven
command for the suite is
mvn -DtestIgniteBinaryCacheQueryTestSuite -am -pl
Sure, I'll do that.
On Fri, Nov 27, 2020 at 2:00 PM Ilya Kasnacheev
wrote:
> Hello!
>
> You can override these values (module, suites) values when running a suite
> on TC. Can you please run these ones which need to be changed individually
> on TC, make sure they run without errors and contain
Hello!
You can override these values (module, suites) values when running a suite
on TC. Can you please run these ones which need to be changed individually
on TC, make sure they run without errors and contain all the needed tests,
and link to these runs in the ticket? Then I can modify the
Hi, sorry for the misleading. I mean "adding ignite-core module *suites* to
the TeamCity Queries* suite"
On Fri, Nov 27, 2020 at 12:44 PM Ilya Kasnacheev
wrote:
> Hello!
>
> What do you mean by "adding ignite-core to suite"? ignite-core is a top
> dependency and its tests are also included in
Hello!
What do you mean by "adding ignite-core to suite"? ignite-core is a top
dependency and its tests are also included in all other modules' tests
classpath since it provides GridAbstractTest.
Regards,
--
Ilya Kasnacheev
пт, 27 нояб. 2020 г. в 01:24, Max Timonin :
> Hi, Ilya!
>
> So, I've
Hi, Ilya!
So, I've updated PR, fixed comments and removed Core* prefixes. MTCGA shows
no blockers, but it was 2 weeks ago, so I've started it again.
If PR is OK then there are some suites that should be updated on TC. Could
you please tell me how we can do it?
1. Add
Hello!
Yes, we have such tests which depend on ignite-indexing or ignite-spring.
They just need to be included in Spring* or Queries* test suite. Then they
will be executed on TC in the correct context. You can also run these tests
from IDEA by specifying other module as classpath. No need to
>> WDYT?
LGTM
On Wed, Nov 25, 2020 at 12:23 AM Max Timonin
wrote:
> Ilya, Anton, Ivan, hi!
>
> I fix some comments you leave in the PR. Also I checked some test suites
> and found that some tests are written in the core module but depend on the
> indexing module (or other modules). Some of such
Ilya, Anton, Ivan, hi!
I fix some comments you leave in the PR. Also I checked some test suites
and found that some tests are written in the core module but depend on the
indexing module (or other modules). Some of such test classes contain tests
that are related to the core functionality, but
Hi Ilya! Thank you for up the topic. I will come back with fixes and
comments in a couple of days.
On Tue, Nov 17, 2020 at 4:26 PM Ilya Kasnacheev
wrote:
> Hello!
>
> I have left some comments and there's also more discussion there. Can you
> please look?
>
> Thanks,
> --
> Ilya Kasnacheev
>
>
Hello!
I have left some comments and there's also more discussion there. Can you
please look?
Thanks,
--
Ilya Kasnacheev
вт, 3 нояб. 2020 г. в 00:03, Max Timonin :
> Hi!
>
> I've updated PR: https://github.com/apache/ignite/pull/8367. Anton, Ivan,
> Ivan could you please review it?
>
> Some
Hi!
I've updated PR: https://github.com/apache/ignite/pull/8367. Anton, Ivan,
Ivan could you please review it?
Some moments to mention:
1. I've added new suites: SerializerSuite (ignite-cassandra-serializers),
DistanceTestSuite, NaiveBayesTestSuite (ignite-ml). Should we configure a
TeamCity to
> As I understand we
> can't just move suites between modules, as TeamCity may depend on the path
> to them.
See no problem to update TC as well.
On Fri, Oct 30, 2020 at 4:32 PM Ivan Daschinsky wrote:
> I suggests to mark these tests with @Ignore and file tickets to fix them.
>
> пт, 30 окт.
I suggests to mark these tests with @Ignore and file tickets to fix them.
пт, 30 окт. 2020 г. в 16:26, Ivan Daschinsky :
> Hi
>
> WalCompactionAfterRestartTest -- yes we need it. This test failed because
> of race (test shold be rewritten a little bit)
>
> пт, 30 окт. 2020 г. в 16:15, Max
Hi
WalCompactionAfterRestartTest -- yes we need it. This test failed because
of race (test shold be rewritten a little bit)
пт, 30 окт. 2020 г. в 16:15, Max Timonin :
> Hi!
>
> Yes, you're correct. I've developed the check and started to clean tests
> (move them to suites, mark some tests with
Hi!
Yes, you're correct. I've developed the check and started to clean tests
(move them to suites, mark some tests with Ignore, etc.). I finish work on
the core module. I hope it was the biggest one, and others are less. If so,
I think I will finish the work on other modules in 1 or 2 weeks, as I
Folks,
What's the current state of this thread?
AFAIU, we found unused and wrongly located tests and developed some
checker, could we split this to some PRs?
Let's merge tests usage fix and location fixes first, this will provide us
an ability to automate check using Travis.
On Tue, Oct 20, 2020
Max, Ivan,
Using explicit @Ignore and the automated check sounds good to me. If
nobody has arguments against it I think we should do it.
2020-10-19 19:30 GMT+03:00, Max Timonin :
> Hi Ivan,
>
> I've checked the ticket you provide. It contains subtasks to uncomment or
> to remove some unused
Hi Ivan,
I've checked the ticket you provide. It contains subtasks to uncomment or
to remove some unused tests. It definitely describes some cases I've found.
So what do you think if I uncomment them in suites, add @Ignore annotation
for those tests while the tickets are open? This will help to
Ivan, as far as I understand, Max also created verification check for not
included test and found a few tests, that have never been included in any
testsuites.
Also, I suppose, that even if we cannot run some tests, these tests should
be ignored using annotation, but not commented.
пн, 19 окт.
Hi Max,
There is an existing effort about "abandoned" tests
https://issues.apache.org/jira/browse/IGNITE-9210
2020-10-19 16:25 GMT+03:00, Max Timonin :
> Hi Igniters!
>
> I made a research into tests that aren't included in any test suite. As
> TeamCity runs tests by suites so there could be
Hi Igniters!
I made a research into tests that aren't included in any test suite. As
TeamCity runs tests by suites so there could be tests that never run on TC.
So I tried implementing a simple check for such tests and include it in
Ignite's travis config.
The check runs while "mvn test" command
53 matches
Mail list logo
