[
https://issues.apache.org/jira/browse/SOLR-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16162164#comment-16162164
]
Mano Kovacs commented on SOLR-10912:
------------------------------------
The latest test-patch only tested the three module was changed (either my
intentional error was not placed correctly, or we need more tests there).
bq. A change in solr-core shouldn't need to re-run the solrj unit tests, but a
solrj change would benefit from running the solr unit tests.
Yeah, solr depends on solrj, so the direction is correct. It is matter of view
to say that a module's API should be validated through it's unittests or the
tests of other modules depending on it (in this case solr->solrj).
But for start, if that won't cause too much load on the jenkins, we can tests
rather more than less.
Could we define all the transitive triggers for unittest between modules?
* solrj->solr-core
* lucene->solr?
Any other?
> Adding automatic patch validation
> ---------------------------------
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
> Reporter: Mano Kovacs
> Attachments: SOLR-10912.sample-patch.patch,
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or
> other Apache projects are using (see link). This would ensure that every
> patch passes a certain set of criterions before getting approved. It would
> save time for developer (faster feedback loop), save time for committers
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be
> a good direction to start. This jira could be the board of discussing the
> preferred solution.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
