That was a very useful point Kevin, it seems that the tests are not excluded with -x test. After some trial-and-error, I believe the easiest solution is to exclude them explicitly whenever "test" is excluded. I have created https://github.com/apache/solr/pull/3184 for that.
I believe the affected test tasks are wired with check instead of test, and excluding the test task does not explicitly exclude those. There were a few other observations and issues related to the type of these test tasks and the tests themselves that I will try to address in separate PRs. On Thu, Feb 13, 2025 at 5:10 PM Kevin Risden <kris...@apache.org> wrote: > A side note regardless of the actual dependencies in question here. I would > NOT expect any tests to be run for this Jenkins job. The jenkins job runs > this command: > > /home/jenkins/jenkins-slave/workspace/Solr/Solr-Lint-main/gradlew > -Dtests.haltonfailure=false -Dtests.badapples=false --continue precommit > check -x test > > This explicitly disables tests so I don't expect any tests to run. I would > guess that the admin UI stuff is just hooked up to a different part of the > lifecycle. > > Kevin Risden > > > On Thu, Feb 13, 2025 at 9:56 AM Christos Malliaridis < > c.malliari...@gmail.com> wrote: > > > Thanks for pinging, > > > > The issue is caused by the UI tests for the browser builds. In the gradle > > configuration of the ui module I explicitly chose to run the tests on a > > headless chrome browser, but that was just a wild guess. Since the checks > > passed on the PR, I believed that would be sufficient, but it seems that > a > > few of our CI servers have not installed chrome. > > > > Do we have for the current webapp any specific browser installed on our > CI > > servers that we could use for testing? Otherwise I will turn off the > wasmJs > > test execution and run the tests only for JVM. > > > > Theoretically we could also conditionally disable wasmJs when it is a CI > > build, but doing so would affect the lock file in > > kotlin-js-store/yarn.lock, resulting in different dependencies based on > the > > enabled state. And we still don't have any guarantee that a developer has > > installed chrome or any other browser for testing. And I am not aware of > > any other workarounds. > > > > Best, > > Christos > > > > On Thu, Feb 13, 2025 at 4:22 AM David Smiley <dsmi...@apache.org> wrote: > > > > > Looks like some CI builds are failing since the merge of the new admin > > > UI. Can you take a look please Christos? > > > > > > On Wed, Feb 12, 2025 at 7:09 PM Apache Jenkins Server < > > > jenk...@builds.apache.org> wrote: > > > > > >> Build: https://ci-builds.apache.org/job/Solr/job/Solr-Lint-main/97/ > > >> > > >> No tests ran. > > >> > > >> Build Log: > > >> [...truncated 1214 lines...] > > >> BUILD FAILED in 12m 1s > > >> 618 actionable tasks: 618 executed > > >> > > >> Publishing build scan... > > >> https://develocity.apache.org/s/4llqv2ez5gllq > > >> > > >> Build step 'Invoke Gradle script' changed build result to FAILURE > > >> Build step 'Invoke Gradle script' marked build as failure > > >> Archiving artifacts > > >> Email was triggered for: Failure - Any > > >> Sending email for trigger: Failure - Any > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: builds-unsubscr...@solr.apache.org > > >> For additional commands, e-mail: builds-h...@solr.apache.org > > > > > > > > >
