Re: [jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
I think I misunderstood the intent of this jira. This is not a user facing
api, as I originally thought, but rather a refactoring of internal code
with respect to how various components access configuration pieces of Solr.
If that is the correct understanding, please go ahead as soon as possible
without SIP and this is something which is important and needed and voting
on this seems unnecessary.
On Wed, 9 Sep, 2020, 1:27 am David Smiley (Jira), wrote:
>
> [
> https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192425#comment-17192425
> ]
>
> David Smiley commented on SOLR-14843:
> -
>
> Yeah a SIP. Lets look at this in a light-weight way... copy-paste to a
> Confluence doc, and start a dev list discussion pointing to it, perhaps
> with the same text in the email as well. The dev list discussion enhances
> visibility about SIP-worthy matters. The SIP part I'm more dubious on is
> voting, but it could be very lazy-consensus -- at some point say what you
> plan to do and just start doing it unless you get a veto. CC [~janhoy]
>
> [~ilan] Code/config evolution is a general issue that is not specific to
> this proposal. I've seen the first option you list (code2 reads config1)
> used most often. It's basically the writer of the code in question to deal
> with this, not the platform. It's not clear to me how this proposal would
> be modified to handle this concern in the platform itself... and I'm a
> little skeptical about wether it should.
>
> > Define strongly-typed cluster configuration API
> > ---
> >
> > Key: SOLR-14843
> > URL: https://issues.apache.org/jira/browse/SOLR-14843
> > Project: Solr
> > Issue Type: Improvement
> > Security Level: Public(Default Security Level. Issues are Public)
> >Reporter: Andrzej Bialecki
> >Priority: Major
> > Labels: clean-api
> > Fix For: master (9.0)
> >
> >
> > Current cluster-level configuration uses a hodgepodge of traditional
> Solr config sources (solr.xml, system properties) and the new somewhat
> arbitrary config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each
> config source has its own CRUD, often relying on direct access to
> Zookeeper. There's also no uniform method for monitoring changes to these
> config sources.
> > This issue proposes a uniform config API facade with the following
> characteristics:
> > * Using a single hierarchical (or at least key-based) facade for
> accessing any global config.
> > * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they
> would use properly annotated Java objects for config CRUD. Config objects
> would include versioning information (eg. lastModified timestamp).
> > * Isolating access to the underlying config persistence layer:
> components would no longer directly interact with Zookeeper or files. Most
> likely the default implementation would continue using different ZK files
> per-subsystem in order to limit the complexity of file formats and to
> reduce the cost of notifications for unmodified parts of the configs.
> > * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they
> are interested in.
>
>
>
> --
> 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
>
>
Re: Tests that use bin/solr?
I never really looked at the smoketester before today. smokeTestRelease.py does very very little with a running Solr instance -- just run techproducts and do a query. testSolrExample() is the function where this happens. Unless I'm missing something lots more, I can confidently say that the docker-solr project's tests actually test the final Solr instance substantially more than our project does. https://github.com/docker-solr/docker-solr/tree/master/tests I'd like to see the Solr project incorporating the docker-solr tests into nightly CI builds somehow. We'll be much closer to making this happen once docker-solr is absorbed into Solr -- https://github.com/apache/lucene-solr/pull/1769 because we'll be able to have nightly builds of images. The docker-solr separate project is limited to releases, which poses a distinct chicken-and-egg problem. Maybe those tests could themselves run from a Docker image, thus insulating platform issues further. Separately, someday I do want to work on running SolrExampleTests against the docker image, which will be more possible once the projects merge. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Tue, Sep 8, 2020 at 8:02 AM Jason Gerlowski wrote: > I created a few JIRAs to spike "bin/solr" tests several years back > (SOLR-11749). I didn't have quite enough time to get it across the finish > line previously but I think it's a great idea to have tests of this sort. > At the time I was writing tests in bash - but realized that wasn't a > particularly scalable approach. > > Would be happy to help where I can if the effort gets restarted. > > Best, > > Jason > > On Mon, Sep 7, 2020 at 3:14 AM Uwe Schindler wrote: > >> It should be part of an integration test suite, only on module "package" >> after assembly. That's something to setup. Please make sure that it works >> with any operating system, because we are leaving Java world here (and >> because of this, don't mix that into default unit tests). >> >> Currently we have a test for bin/solr: Smoketester >> >> Uwe >> >> - >> Uwe Schindler >> Achterdiek 19, D-28357 Bremen >> https://www.thetaphi.de >> eMail: u...@thetaphi.de >> >> > -Original Message- >> > From: Dawid Weiss >> > Sent: Monday, September 7, 2020 9:00 AM >> > To: Lucene Dev >> > Subject: Re: Tests that use bin/solr? >> > >> > Just a note - such integration tests should depend on (and consume) >> > the output of solr/packaging (a ZIP file with fully assembled >> > package). Then you're really sure you're testing the final artifact. >> > >> > Dawid >> > >> > On Mon, Sep 7, 2020 at 7:51 AM David Smiley wrote: >> > > >> > > Do we have any tests that operate on a "real" Solr instance running >> from >> > "bin/solr"? Such tests could find problems with bin/solr and any >> classpath >> > matters in how Jetty operates. Solr does have JettySolrRunner which is >> great >> > but doesn't cover the aforementioned matters. >> > > >> > > We've got some really nice tests in SolrExampleTests which is a base >> class and >> > many implementations that create SolrJ clients in different ways. I >> could >> > imagine modifying this such that if a magic system property is >> specified to a >> > URL of an existing Solr instance, then the test would not create a >> > JettySolrRunner but instead use the configured one. This would then be >> > executed by the smoke tester and maybe a future Docker release >> process. I >> > have test infrastructure I wrote where I work that does this sort of >> thing for our >> > Solr plugins, and it works great. >> > > >> > > ~ David Smiley >> > > Apache Lucene/Solr Search Developer >> > > http://www.linkedin.com/in/davidwsmiley >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: [VOTE] Lucene logo contest, third time's a charm
Thank you, Ryan and everyone else who was involved! Looking forward to the new Logo. It's been a while :) On Tue, Sep 8, 2020 at 8:55 AM Ryan Ernst wrote: > This vote is now closed. The results are as follows: > > Binding Results > A1: 12 (55%) > D: 6 (27%) > A2: 4 (18%) > > All Results > A1: 16 (55%) > D: 7 (24%) > A2: 5 (17%) > B5d: 1 (3%) > > A1 is our winner! I will make the necessary changes. > > Thank you to Dustin Haver, Stamatis Zampetakis, Baris Kazar and all who > voted! > > On Tue, Sep 1, 2020 at 1:21 PM Ryan Ernst wrote: > > > Dear Lucene and Solr developers! > > > > Sorry for the multiple threads. This should be the last one. > > > > In February a contest was started to design a new logo for Lucene > > [jira-issue]. The initial attempt [first-vote] to call a vote resulted in > > some confusion on the rules, as well the request for one additional > > submission. The second attempt [second-vote] yesterday had incorrect > links > > for one of the submissions. I would like to call a new vote, now with > more > > explicit instructions on how to vote, and corrected links. > > > > *Please read the following rules carefully* before submitting your vote. > > > > *Who can vote?* > > > > Anyone is welcome to cast a vote in support of their favorite > > submission(s). Note that only PMC member's votes are binding. If you are > a > > PMC member, please indicate with your vote that the vote is binding, to > > ease collection of votes. In tallying the votes, I will attempt to verify > > only those marked as binding. > > > > > > *How do I vote?* > > Votes can be cast simply by replying to this email. It is a ranked-choice > > vote [rank-choice-voting]. Multiple selections may be made, where the > order > > of preference must be specified. If an entry gets more than half the > votes, > > it is the winner. Otherwise, the entry with the lowest number of votes is > > removed, and the votes are retallied, taking into account the next > > preferred entry for those whose first entry was removed. This process > > repeats until there is a winner. > > > > The entries are broken up by variants, since some entries have multiple > > color or style variations. The entry identifiers are first a capital > > letter, followed by a variation id (described with each entry below), if > > applicable. As an example, if you prefer variant 1 of entry A, followed > by > > variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant > 4e > > of entry B, the following should be in your reply: > > > > (binding) > > vote: A1, A2, C3, D, B4e > > > > *Entries* > > > > The entries are as follows: > > > > A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2. > > > > [A1] > > > https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png > > [A2] > > https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png > > > > B. Submitted by Stamatis Zampetakis. This has several variants. Within > the > > linked entry there are 7 patterns and 7 color palettes. Any vote for B > > should contain the pattern number followed by the lowercase letter of the > > color palette. For example, B3e or B1a. > > > > [B] > > > https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf > > > > C. Submitted by Baris Kazar. This entry has 8 variants. > > > > [C1] > > > https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf > > [C2] > > > https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf > > [C3] > > > https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf > > [C4] > > > https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf > > [C5] > > > https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf > > [C6] > > > https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf > > [C7] > > > https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf > > [C8] > > > https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf > > > > D. The current Lucene logo. > > > > [D] > > https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png > > > > Please vote for one of the above choices. This vote will close about one > > week from today, Mon, Sept 7, 2020 at 11:59PM. > > > > Thanks! > > > > [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221 > > [first-vote] > > > http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e > > [second-vote] > > > http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e > > [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting > > > -- Anshum Gupta
Re: [VOTE] Lucene logo contest, third time's a charm
Thank you ryan for pushing on this, being persistent and getting the vote out. On Tue, Sep 8, 2020 at 5:55 PM Ryan Ernst wrote: > This vote is now closed. The results are as follows: > > Binding Results > A1: 12 (55%) > D: 6 (27%) > A2: 4 (18%) > > All Results > A1: 16 (55%) > D: 7 (24%) > A2: 5 (17%) > B5d: 1 (3%) > > A1 is our winner! I will make the necessary changes. > > Thank you to Dustin Haver, Stamatis Zampetakis, Baris Kazar and all who > voted! > > On Tue, Sep 1, 2020 at 1:21 PM Ryan Ernst wrote: > > > Dear Lucene and Solr developers! > > > > Sorry for the multiple threads. This should be the last one. > > > > In February a contest was started to design a new logo for Lucene > > [jira-issue]. The initial attempt [first-vote] to call a vote resulted in > > some confusion on the rules, as well the request for one additional > > submission. The second attempt [second-vote] yesterday had incorrect > links > > for one of the submissions. I would like to call a new vote, now with > more > > explicit instructions on how to vote, and corrected links. > > > > *Please read the following rules carefully* before submitting your vote. > > > > *Who can vote?* > > > > Anyone is welcome to cast a vote in support of their favorite > > submission(s). Note that only PMC member's votes are binding. If you are > a > > PMC member, please indicate with your vote that the vote is binding, to > > ease collection of votes. In tallying the votes, I will attempt to verify > > only those marked as binding. > > > > > > *How do I vote?* > > Votes can be cast simply by replying to this email. It is a ranked-choice > > vote [rank-choice-voting]. Multiple selections may be made, where the > order > > of preference must be specified. If an entry gets more than half the > votes, > > it is the winner. Otherwise, the entry with the lowest number of votes is > > removed, and the votes are retallied, taking into account the next > > preferred entry for those whose first entry was removed. This process > > repeats until there is a winner. > > > > The entries are broken up by variants, since some entries have multiple > > color or style variations. The entry identifiers are first a capital > > letter, followed by a variation id (described with each entry below), if > > applicable. As an example, if you prefer variant 1 of entry A, followed > by > > variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant > 4e > > of entry B, the following should be in your reply: > > > > (binding) > > vote: A1, A2, C3, D, B4e > > > > *Entries* > > > > The entries are as follows: > > > > A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2. > > > > [A1] > > > https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png > > [A2] > > https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png > > > > B. Submitted by Stamatis Zampetakis. This has several variants. Within > the > > linked entry there are 7 patterns and 7 color palettes. Any vote for B > > should contain the pattern number followed by the lowercase letter of the > > color palette. For example, B3e or B1a. > > > > [B] > > > https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf > > > > C. Submitted by Baris Kazar. This entry has 8 variants. > > > > [C1] > > > https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf > > [C2] > > > https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf > > [C3] > > > https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf > > [C4] > > > https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf > > [C5] > > > https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf > > [C6] > > > https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf > > [C7] > > > https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf > > [C8] > > > https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf > > > > D. The current Lucene logo. > > > > [D] > > https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png > > > > Please vote for one of the above choices. This vote will close about one > > week from today, Mon, Sept 7, 2020 at 11:59PM. > > > > Thanks! > > > > [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221 > > [first-vote] > > > http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e > > [second-vote] > > > http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e > > [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting > > >
Re: [VOTE] Lucene logo contest, third time's a charm
This vote is now closed. The results are as follows: Binding Results A1: 12 (55%) D: 6 (27%) A2: 4 (18%) All Results A1: 16 (55%) D: 7 (24%) A2: 5 (17%) B5d: 1 (3%) A1 is our winner! I will make the necessary changes. Thank you to Dustin Haver, Stamatis Zampetakis, Baris Kazar and all who voted! On Tue, Sep 1, 2020 at 1:21 PM Ryan Ernst wrote: > Dear Lucene and Solr developers! > > Sorry for the multiple threads. This should be the last one. > > In February a contest was started to design a new logo for Lucene > [jira-issue]. The initial attempt [first-vote] to call a vote resulted in > some confusion on the rules, as well the request for one additional > submission. The second attempt [second-vote] yesterday had incorrect links > for one of the submissions. I would like to call a new vote, now with more > explicit instructions on how to vote, and corrected links. > > *Please read the following rules carefully* before submitting your vote. > > *Who can vote?* > > Anyone is welcome to cast a vote in support of their favorite > submission(s). Note that only PMC member's votes are binding. If you are a > PMC member, please indicate with your vote that the vote is binding, to > ease collection of votes. In tallying the votes, I will attempt to verify > only those marked as binding. > > > *How do I vote?* > Votes can be cast simply by replying to this email. It is a ranked-choice > vote [rank-choice-voting]. Multiple selections may be made, where the order > of preference must be specified. If an entry gets more than half the votes, > it is the winner. Otherwise, the entry with the lowest number of votes is > removed, and the votes are retallied, taking into account the next > preferred entry for those whose first entry was removed. This process > repeats until there is a winner. > > The entries are broken up by variants, since some entries have multiple > color or style variations. The entry identifiers are first a capital > letter, followed by a variation id (described with each entry below), if > applicable. As an example, if you prefer variant 1 of entry A, followed by > variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e > of entry B, the following should be in your reply: > > (binding) > vote: A1, A2, C3, D, B4e > > *Entries* > > The entries are as follows: > > A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2. > > [A1] > https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png > [A2] > https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png > > B. Submitted by Stamatis Zampetakis. This has several variants. Within the > linked entry there are 7 patterns and 7 color palettes. Any vote for B > should contain the pattern number followed by the lowercase letter of the > color palette. For example, B3e or B1a. > > [B] > https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf > > C. Submitted by Baris Kazar. This entry has 8 variants. > > [C1] > https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf > [C2] > https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf > [C3] > https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf > [C4] > https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf > [C5] > https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf > [C6] > https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf > [C7] > https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf > [C8] > https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf > > D. The current Lucene logo. > > [D] > https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png > > Please vote for one of the above choices. This vote will close about one > week from today, Mon, Sept 7, 2020 at 11:59PM. > > Thanks! > > [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221 > [first-vote] > http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e > [second-vote] > http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e > [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting >
RE: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 175 - Still Failing!
It failed because of this: * What went wrong: Execution failed for task ':lucene:changesToHtml'. > Changes generation failed: Section 'Other' appears more than once under release '8.7.0' at /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-Check-master/lucene/site/changes/changes2html.pl line 136. The InterruptedException issue you are seeing is caused by Jenkins itsself, but does not fail build (happens on almost every build). It's caused by the javac warning scanner. Known issue, fixed in later plugin versions. Does not cause this failure. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Dawid Weiss > Sent: Tuesday, September 8, 2020 2:21 PM > To: Lucene Dev > Cc: bui...@lucene.apache.org > Subject: Re: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 175 - Still > Failing! > > https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Check- > master/179/console > > The build passed, actually but something failed later (in jenkins?): > > BUILD SUCCESSFUL in 1h 7m 58s > 790 actionable tasks: 790 executed > Build step 'Invoke Gradle script' changed build result to SUCCESS > Archiving artifacts > java.lang.InterruptedException: no matches found within 1 > > D. > > On Tue, Sep 8, 2020 at 2:24 AM Apache Jenkins Server > wrote: > > > > Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Check- > master/175/ > > > > All tests passed > > > > Build Log: > > [...truncated 1452 lines...] > > BUILD FAILED in 1h 8m 27s > > 789 actionable tasks: 789 executed > > Build step 'Invoke Gradle script' changed build result to FAILURE > > Build step 'Invoke Gradle script' marked build as failure > > Archiving artifacts > > Recording test results > > Email was triggered for: Failure - Any > > Sending email for trigger: Failure - Any > > > > - > > To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org > > For additional commands, e-mail: builds-h...@lucene.apache.org > > - > To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org > For additional commands, e-mail: builds-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 175 - Still Failing!
https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Check-master/179/console The build passed, actually but something failed later (in jenkins?): BUILD SUCCESSFUL in 1h 7m 58s 790 actionable tasks: 790 executed Build step 'Invoke Gradle script' changed build result to SUCCESS Archiving artifacts java.lang.InterruptedException: no matches found within 1 D. On Tue, Sep 8, 2020 at 2:24 AM Apache Jenkins Server wrote: > > Build: > https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Check-master/175/ > > All tests passed > > Build Log: > [...truncated 1452 lines...] > BUILD FAILED in 1h 8m 27s > 789 actionable tasks: 789 executed > Build step 'Invoke Gradle script' changed build result to FAILURE > Build step 'Invoke Gradle script' marked build as failure > Archiving artifacts > Recording test results > Email was triggered for: Failure - Any > Sending email for trigger: Failure - Any > > - > To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org > For additional commands, e-mail: builds-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Tests that use bin/solr?
I created a few JIRAs to spike "bin/solr" tests several years back (SOLR-11749). I didn't have quite enough time to get it across the finish line previously but I think it's a great idea to have tests of this sort. At the time I was writing tests in bash - but realized that wasn't a particularly scalable approach. Would be happy to help where I can if the effort gets restarted. Best, Jason On Mon, Sep 7, 2020 at 3:14 AM Uwe Schindler wrote: > It should be part of an integration test suite, only on module "package" > after assembly. That's something to setup. Please make sure that it works > with any operating system, because we are leaving Java world here (and > because of this, don't mix that into default unit tests). > > Currently we have a test for bin/solr: Smoketester > > Uwe > > - > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: u...@thetaphi.de > > > -Original Message- > > From: Dawid Weiss > > Sent: Monday, September 7, 2020 9:00 AM > > To: Lucene Dev > > Subject: Re: Tests that use bin/solr? > > > > Just a note - such integration tests should depend on (and consume) > > the output of solr/packaging (a ZIP file with fully assembled > > package). Then you're really sure you're testing the final artifact. > > > > Dawid > > > > On Mon, Sep 7, 2020 at 7:51 AM David Smiley wrote: > > > > > > Do we have any tests that operate on a "real" Solr instance running > from > > "bin/solr"? Such tests could find problems with bin/solr and any > classpath > > matters in how Jetty operates. Solr does have JettySolrRunner which is > great > > but doesn't cover the aforementioned matters. > > > > > > We've got some really nice tests in SolrExampleTests which is a base > class and > > many implementations that create SolrJ clients in different ways. I > could > > imagine modifying this such that if a magic system property is specified > to a > > URL of an existing Solr instance, then the test would not create a > > JettySolrRunner but instead use the configured one. This would then be > > executed by the smoke tester and maybe a future Docker release process. > I > > have test infrastructure I wrote where I work that does this sort of > thing for our > > Solr plugins, and it works great. > > > > > > ~ David Smiley > > > Apache Lucene/Solr Search Developer > > > http://www.linkedin.com/in/davidwsmiley > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
