All right - thanks for reviewing the plan guys! I've updated the jobs in Jenkins, and after sorting out a JDK21-related hiccup or two, everything looks to be healthy. (Or, as healthy as our test runs typically are *sigh*)
I've got a PR to update a few references to the Jenkins jobs in our READMe and docs: take a look if you get a chance! https://github.com/apache/solr/pull/2827 Best, Jason On Fri, Oct 25, 2024 at 5:46 AM Eric Pugh <de...@yahoo.com.invalid> wrote: > > I had no idea how deep our testing went! > > All makes sense! > > Sent from my iPhone > > > On Oct 24, 2024, at 10:16 PM, David Smiley <dsmi...@apache.org> wrote: > > > > Sounds very good Jason; thanks for the summary and execution of the plan. > > > >> On Thu, Oct 24, 2024 at 3:56 PM Jason Gerlowski <gerlowsk...@gmail.com> > >> wrote: > >> > >> My original writeup here missed one important detail that Uwe recently > >> clarified for me on the lucene lists. [1]. The constant presence of > >> some Solr jobs in the Jenkins build-queue isn't accidental, it's by > >> design(!) We've historically triggered some jobs "hourly" instead of > >> "nightly" in order to get the maximum number of test-runs / > >> randomization-seeds out of our hardware. > >> > >> This doesn't eliminate the need for the deduplication I mentioned > >> originally, though it would change a bit how we go about that, since > >> it sounds like it still makes sense to run our tests (and only our > >> tests) in as tight a loop as possible. My updated suggestion would be > >> to: > >> > >> 1. Switch the Solr-reference-guide jobs to be built "daily" instead of > >> the current "hourly". > >> 2. Split the 'Solr-Check' job into two jobs: a "daily" job running > >> static analysis targets, and an "hourly" job running only the tests > >> 3. (Optional) Split 'integrationTests' into their own job, since > >> they're somewhat time consuming and don't use randomization and > >> probably don't benefit much from being run "hourly" > >> > >> This would leave a single job responsible for testing that is > >> triggered "hourly", with all other jobs being run "daily". Any > >> objections to this revised plan? I'll assume lazy-consensus and make > >> the changes sometime next week. > >> > >> Best, > >> > >> Jason > >> > >> [1] https://lists.apache.org/thread/t2ot2l2nyyrjv8q676ok757b7hohqsy5 > >> > >>> On Tue, Oct 15, 2024 at 12:40 PM Jan Høydahl <jan....@cominvent.com> > >>> wrote: > >>> > >>> +1. cleanups always good. Also, do we need to keep the smoke test 9.7 > >> running if we don’t think there will be a 9.7.1 release? > >>> > >>> Jan Høydahl > >>> > >>>> On 15 Oct 2024, at 14:32, David Smiley <dsmi...@apache.org> wrote: > >>>> > >>>> +1 Sure; seems like a simple solution. > >>>> > >>>>> On Tue, Oct 15, 2024 at 7:27 AM Jason Gerlowski < > >> gerlowsk...@gmail.com> > >>>>> wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> While cleaning up our Jenkins agents, I noticed that we trigger a lot > >>>>> of long-running (> 1 hr) jobs on a nightly basis. Each family of jobs > >>>>> differs slightly in the gradle task it runs, but there's a lot of > >>>>> overlap. e.g. our 'Solr-Check', 'Solr-Smoketest', and > >>>>> 'Solr-NightlyTests' builds all run our test suite. Combine this with > >>>>> the limited Jenkins hardware we have access to, and it's a recipe for > >>>>> contention. > >>>>> > >>>>> Nightly jobs alone keep our Jenkins agents pegged for at least half > >>>>> the day! This makes us a bad "neighbor" on these boxes. It also > >>>>> prevents us from firing off ad-hoc jobs or doing anything more > >>>>> inventive or rigorous (like multi-JVMs testing) etc. > >>>>> > >>>>> What do you all think of deduplicating the work done by our Jenkins > >>>>> setup? I'm not attached to any particular breakdown, but one example > >>>>> would be to explicitly run 'test' in the 'NightlyTests' job and then > >>>>> exclude the task from running as a part of the 'Check' and 'Smoketest' > >>>>> jobs. > >>>>> > >>>>> Best, > >>>>> > >>>>> Jason > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >>>>> For additional commands, e-mail: dev-h...@solr.apache.org > >>>>> > >>>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >>> For additional commands, e-mail: dev-h...@solr.apache.org > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >> For additional commands, e-mail: dev-h...@solr.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
