[
https://issues.apache.org/jira/browse/SOLR-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17285503#comment-17285503
]
Chris M. Hostetter commented on SOLR-15149:
-------------------------------------------
well ... i mean ... step #1 is to always run tests before pushing to any shared
branch ... i have no idea what a gree lite on github means, but i wouldn't
assume it means much more then "git merge doesn't fail" -- but even if it was
running tests, that shouldn't amtter. Github is a 3rd party, unofficial,
provider or a mirror of our ASF repo -- and no github tool/feature should be
neccessary or sufficient to decide what code should be in what should be pushed
to the ASF repo. As committers our (minimum) level of responsibility should be
to only push changes that we've personally vetted (at least once) ... and in
the case of making code/test changes that should mean "personally running the
tests"
As far as knowing when jenkins builds fail: there are at least 6 jenkins builds
i can think of off the top of my head w/o looking at the list - not all of them
run tests. Subscribing to builds@lucene is the fastest way to know when
jenkins jobs are failing.
I've also got this system setup that monitors jenkins failures for lucene-solr
to try and find patterns, but it lags by a few hours, and is also just a 3rd
party, unofficial, tool. It should also not viewed as neccessary/sufficient
for the purposes of evaluating quality of commits/tests: it's just a starting
point for people to do their own homework...
http://fucit.org/solr-jenkins-reports/failure-report.html
> Learning To Rank model upload fails generically
> -----------------------------------------------
>
> Key: SOLR-15149
> URL: https://issues.apache.org/jira/browse/SOLR-15149
> Project: Solr
> Issue Type: Bug
> Components: contrib - LTR
> Reporter: Alessandro Benedetti
> Assignee: Alessandro Benedetti
> Priority: Major
> Fix For: 8.9
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When uploading a model, using a not existent store or other incorrect
> parameters you get:
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","java.lang.ClassCastException"],
> "msg":"org.apache.solr.ltr.model.ModelException: Model type does not
> exist org.apache.solr.ltr.model.LinearModel",
> "code":400}}
> In the response, logs don't help that much out of the box, I had to go for
> remote debugging and of course we don't want the generic user to do that.
> Reason is in org/apache/solr/ltr/model/LTRScoringModel.java:111
> {code:java}
> try {
> // create an instance of the model
> model = solrResourceLoader.newInstance(
> className,
> LTRScoringModel.class,
> new String[0], // no sub packages
> new Class[] { String.class, List.class, List.class, String.class,
> List.class, Map.class },
> new Object[] { name, features, norms, featureStoreName,
> allFeatures, params });
> if (params != null) {
> SolrPluginUtils.invokeSetters(model, params.entrySet());
> }
> } catch (final Exception e) {
> throw new ModelException("Model type does not exist " + className, e);
> }
> {code}
> This happens when:
> - use a not existent feature store
> - use not existent feature
> - use an integer instead of Double as a weight in a linear model
> unless any objection, we should improve such message with the real one
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
