Sonatype-lift giving a passing review on a PR is not a qualification we have on our project to merge. Therefore it's also pointless to tell it to "ignore" anything. The bot provides feedback at specific line numbers that we should at least briefly consider; ideally say something about in the comment to show (to each other) that we looked at it. That's it. Perhaps some projects choose to gate merging on Lift's complete validation.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Sun, Nov 7, 2021 at 8:31 PM Gus Heck <[email protected]> wrote: > https://github.com/apache/solr/pull/397 is the new PR for those > interested. Will try to merge it next weekend if no objections are found. > > Am a little unclear on what sonatype-lift is doing. I told it to ignore > one (that I filed a separate ticket for) then made a fix thinking that that > would cull out a couple but not all of the remaining items and then it > seemingly passed review so maybe ignore blocked an entire category of > warnings, not the specific item? > > On Wed, Sep 1, 2021 at 3:12 PM Houston Putman <[email protected]> > wrote: > >> We do not currently have the docker image being built and tested on CI. I >> can get working on that. >> >> On Wed, Sep 1, 2021 at 3:07 PM David Smiley <[email protected]> wrote: >> >>> JettySolrRunner can only do so much. There are other differences >>> between a real running server and JettySolrRunner such as our bin/solr >>> script and probably much and all of our Jetty configuration. I've been >>> bitten by a classpath bug that is really only possible to see when you run >>> things for real. To that end, I think our long term plan on integration >>> testing should be Docker, and don't worry *too much* about how accurate >>> JettySolrRunner runs Solr. We're a major step ahead nowadays with Docker >>> being part of the project. I think the next step is building and running >>> its tests on a CI -- I don't recall if this happens already?. A subsequent >>> step https://issues.apache.org/jira/browse/SOLR-11872 (see last comment >>> summary) to allow more of our tests to work with a managed SolrClient that >>> is pluggable and can use a Solr instance running in Docker in particular. >>> This is how I test our Solr plugins where I work -- using different modes >>> of Solr for different levels of testing and thoroughness. I'll touch on >>> this at an ApacheCon talk later this month. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> >>> On Tue, Aug 31, 2021 at 6:44 PM Chris Hostetter < >>> [email protected]> wrote: >>> >>>> >>>> Gus: I skimmed very little of this mail/thread -- just enough to >>>> recognize >>>> that it's a rabbit hole I'm not ready to devote brain cells to, but >>>> aplaud >>>> your interest in doing so. >>>> >>>> I will comment on just one aspect of your email, only to point you at >>>> some >>>> "prior hole diving" i did, on sub-topic you mentioned, that you may or >>>> may >>>> not find useful... >>>> >>>> : That wasn't too terribly hard, but keeping JettySolrRunner happy was >>>> very >>>> : confusing, and worrisome since I've realized it's not respecting our >>>> : web.xml at all, and any configuration in web.xml needs to be >>>> duplicated for >>>> : our tests in JettySolrRunner (tangent alert) >>>> >>>> https://issues.apache.org/jira/browse/SOLR-14903 >>>> >>>> ...I'm not saying it's a good direction to go in, just that it's a past >>>> experience/mistake you mind find interesting. >>>> >>>> >>>> -Hoss >>>> http://www.lucidworks.com/ >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) >
