I merged https://github.com/apache/solr/pull/4659 into main, and labeled it to go back to 10x.
The next step will be to take advantage of the generated JS code for the Schema Designer, which will cut down on a lot more custom JavaScript in the Solr Admin. I found a limitation in how we generated the OpenAPI spec for for the SchemaDesigner… 10 are great, but 2 are not. This I think is a good example of using the generated code to validate it works the way we want! Once https://github.com/apache/solr/pull/4819 is reviewed and merged we’ll be able to cut over Schema Designer to the generated code! > On Aug 26, 2026, at 11:52 AM, Jason Gerlowski <[email protected]> wrote: > > Closing the loop here: Jan ended up adding some Selenium-based tests > for the Javascript Admin UI in this PR: > https://github.com/apache/solr/pull/4738 > <https://github.com/apache/solr/pull/4738> > > Jason > > On Thu, Aug 13, 2026 at 3:47 PM Chris Hostetter > <[email protected]> wrote: > > > > > > : We continue to support the exact level of Admin UI testing as we’ve had > > : for the past few major versions of Solr ;-). > > : > > : Honestly, for the Admin UI, and you won’t love the answer…. “Please > > : start solr from main and solr on my code branch and compare them using > > : Playwrite”. And it works. Even when I can’t figure out how to spell > > : Playwright. > > > > and that's a totally fine answer for people who are already modifying the > > Admin UI ... i'm just trying to point out that if people are feeling free > > to modify the V2 APIs -- w/o strong concern for backcompat because they > > are experimental -- and trusting that tests will tell them if they've > > broken some client assumption in SolrJ or the SolrCLI, that won't help > > catch sitautions where someone might make a change to a V2 API that breaks > > the UI. > > > > Obviously the same risk exists for the "older" APIs the UI uses -- but > > people (hopefully) are being particularly cautions about making > > back-compat breaks in those legacy APIs because so many things out of our > > control consume them. > > > > > > : It wouldn’t take much to generate a bunch of Admin UI tests, but since > > : that whole UI is not changing much (if any), and we want to move to the > > : new Solr UI, I haven’t seen a strong need to beef up testing, in > > : comparison to other priorities. > > > > I assumed you were talking about "new" UI ... i was asking about tests > > for whatever UI you're planning on modifing to use the V2 stuff :) > > > > > > -Hoss > > http://www.lucidworks.com/ <http://www.lucidworks.com> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
