[wildfly-dev] Re: PR testing with SE 25

On Tue, Mar 10, 2026 at 10:54 AM Yeray Borges Santana <yborgess(a)redhat.com&gt; wrote: > Hello, > > The latest proposal sounds good to me too. If everyone agrees, I'm ready > to change the WildFly Core ones. > Thanks; please do. I'll go ahead with the changes to full WF later this week if there are no further comments.

> > I only want to highlight thst the Bootable JAR jobs in WildFly Core take > only about 20 minutes. The more lengthy ones are about 5h 30m. Not sure if > it could be a good idea, but if we turn the WildFly Core Bootable JAR linux > one into an Integration one, we could use the same Job to test both WildFly > Core and WildFly Bootable JAR testsuite under certain SE so we can gain > some additional coverage in WildFly from the WildFly Core jobs. > Ok with me. That will add about 1:50 mins of CI time per PR.

> In such a case, based on the latest proposal, I would switch WildFly Core > Linux Bootable 17 SE to WildFly Core Linux Bootable Integration SE 21, and > switch WildFly Core Windows Bootable SE 21 to Windows Bootable SE 17 until > we drop the SE 17 support. > 1) I don't see any WildFly Core Windows Bootable SE 21. But if you're referring to my suggestion to move the Windows Bootable 17 to 21 and instead want to leave it at 17 while switching the Linux one to 21, that's fine.

2) Please don't add running full WF bootable jar to the Windows bootable job. Windows agents are a scarce resource and I don't think it's worth it to tie one up for 1:50 more per core PR.

> Although, the gain is minimal and only for Bootable JAR. > > On Tue, Feb 24, 2026 at 10:55 PM Brian Stansberry via wildfly-dev < > wildfly-dev(a)lists.jboss.org&gt; wrote: > >> >> >> On Mon, Feb 23, 2026 at 9:00 AM Richard Opalka via wildfly-dev < >> wildfly-dev(a)lists.jboss.org&gt; wrote: >> >>> Comments inlined: >>> >>> Rio >>> >>> On Sat, Feb 21, 2026 at 9:54 PM Brian Stansberry <bstansbe(a)redhat.com&gt; >>> wrote: >>> >>>> Hi Rio, >>>> >>>> Thanks for the input. >>>> >>>> Proposal 2) is interesting. We also have Linux SM - JDK 17 so we have >>>> SE 17 coverage that way. >>>> >>>> I realize now that soonish when we move std WF to EE 11 we are going >>>> to need testing of the EE 10 variant that we'll provide for a while. So >>>> that's another new use of CI, and probably at least one PR job. >>>> >>> Good point! >>> >>>> >>>> So we have two candidates to drop -- Linux - JDK 17 and Linux >>>> MicroProfile - JDK 17 -- and then we have two new requirements for jobs. >>>> Seems like a match. >>>> >>> >> We're ready right now to add an SE 25 job so I think we should switch >> the Linux MicroProfile - JDK 17 one. And then when we need the EE 10 job we >> replace Linux - JDK 17 with it and rely on Linux SM - JDK !7. >> >> Basically, I don't see much value in Linux MicroProfile - JDK 17 so it's >> the first to go. :) >> >> >>>> Re Proposal 3, SE 17 is still our baseline so personally I'm wary of >>>> dropping all coverage of it in PR testing. >>>> >>> In proposal 3 I was thinking about swapping JDK17 with JDK25 jobs WRT >>> current status quo, i.e. perform JDK 25 testing on every PR and run JDK17 >>> testing nightly (do the switch sometime this year). >>> >> >> We haven't fully qualified SE 25 yet so I think it's too early to >> replace all the SE 17 jobs. Not sure if we'd want to do that before we drop >> SE 17 altogether, but maybe. >> >> But, I do think it's reasonable to shift more of the PR jobs than I >> initially said. We have lots of nightlies; we just want to avoid >> regressions going undetected until someone looks at nightlies. >> >> Perhaps this: >> >> Full WildFly: >> >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WF_PullRequest_BootableJ... >> -- move to SE 25 >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WF_PullRequest_GalleonLi... >> -- move to SE 25 >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WF_PullRequest_LinuxJdk17 >> -- leave for now; will be replaced with an EE 10 job >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WF_PullRequest_LinuxMicr... >> -- drop; add a Linux - JDK 25 >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WF_PullRequest_LinuxSmJdk17 >> -- leave until we drop SE 17 support >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WF_PullRequest_WindowsJdk17 >> -- move to SE 25 >> >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WF_PullRequest_LinuxJdk21 >> -- no change >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WF_PullRequest_WildFlyPr... >> -- move to SE 25 >> >> >> WildFly Core: >> >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequest_... >> -- leave until we drop SE 17 support (full WF uses SE 25) >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequest_.... >> -- move to SE 21 (not 25) just for a bit more SE 21 >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequest_... >> -- move to SE 25 >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequest_... >> -- move to SE 25 >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequest_... >> -- move to SE 25 >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequest_... >> -- leave for now >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequest_... >> -- leave until we drop SE 17 support >> >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequest_... >> (should be named 21 as it uses 21) -- no change >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequest_.... >> -- move to SE 25 >> >> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequest_... >> -- no change >> >> >> >> >>>> I'm not sure what you're saying re EOL. That page shows lots of vendor >>>> support for SE 17 well into 2027 and quite a bit beyond for years beyond >>>> that. >>>> >>> See clarification above ^^^ >>> >>>> >>>> I know you didn't say drop support for SE 17, but it's valid to start >>>> thinking about it. We'd need to give our community notice before dropping >>>> support for an SE version. >>>> >>> Agreed. >>> >>>> >>>> - Brian >>>> >>>> On Sat, Feb 21, 2026 at 1:19 PM Richard Opalka via wildfly-dev < >>>> wildfly-dev(a)lists.jboss.org&gt; wrote: >>>> >>>>> Proposal 3) >>>>> >>>>> Correction: The date of equal ETAs (turning point) will be October >>>>> 2026 and not April 2026. >>>>> >>>>> Rio >>>>> >>>>> On Sat, Feb 21, 2026 at 6:40 PM Richard Opalka <ropalka(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> Let's assign Brian's PR job changes proposal number 1. >>>>>> Below are two other proposals: >>>>>> >>>>>> Proposal 2) >>>>>> >>>>>> For both WildFly Core and WildFly PRs, these three jobs are >>>>>> configured: >>>>>> >>>>>> * Linux - JDK 17 >>>>>> * Linux - JDK 21 >>>>>> * Windows - JDK 17 >>>>>> >>>>>> How about replacing "Linux - JDK 17" with "Linux - JDK 25" ? >>>>>> >>>>>> Proposal 3) >>>>>> >>>>>> Notice that according to [1] the ETA for JDK 17 EOL (6 months) and >>>>>> the ETA since the JDK 25 initial release will be equal in April this >>>>>> year >>>>>> so this might be a good reason to switch all WildFly Core & WildFly >>>>>> PR >>>>>> JDK 17 jobs to JDK 25 variants? >>>>>> >>>>>> [1] https://en.wikipedia.org/wiki/Java_version_history >>>>>> >>>>>> Rio >>>>>> >>>>>> On Thu, Feb 12, 2026 at 12:38 AM Brian Stansberry < >>>>>> bstansberry(a)gmail.com&gt; wrote: >>>>>> >>>>>>> We're continuing to progress with qualifying SE 25 as our >>>>>>> recommended >>>>>>> SE version for WildFly. That's getting close enough that we should >>>>>>> look at what we're doing for PR testing. Currently full WF and WF >>>>>>> Core >>>>>>> are not testing PRs on SE 25. We're relying on nightly jobs to >>>>>>> detect >>>>>>> problems. >>>>>>> >>>>>>> A difficulty is CI is a limited resource and we also want to limit >>>>>>> our >>>>>>> carbon impact, so just adding more jobs for each PR doesn't seem >>>>>>> good. >>>>>>> >>>>>>> Perhaps.... >>>>>>> >>>>>>> On full WF... >>>>>>> >>>>>>> Replace the "Linux MicroProfile - JDK 17" job with a 'Linux - JDK >>>>>>> 25". >>>>>>> >>>>>>> The "Linux MicroProfile" job runs a subset of tests but with server >>>>>>> installation the run the standalone-microprofile.xml config instead >>>>>>> of >>>>>>> standalone.xml. It basically validates that the presence of the MP >>>>>>> stuff in the config doesn't break things. I can't remember the last >>>>>>> time that test detected a problem. Probably not the decade. It >>>>>>> brings >>>>>>> little value. >>>>>>> >>>>>>> Replacing it with a full -DallTests job will mean more resource >>>>>>> consumed per PR though. >>>>>>> >>>>>>> On Core.... >>>>>>> >>>>>>> Reconfigure "WildFly Core -> Preview Integration Linux- JDK 21" to >>>>>>> use >>>>>>> SE 25 instead. >>>>>>> >>>>>>> That leaves nothing running the core TS on 25 though. Perhaps we >>>>>>> could >>>>>>> remove the -DskipTests setting in the step in "WildFly Core -> >>>>>>> Preview >>>>>>> Integration Linux- JDK 21" that builds core. >>>>>>> >>>>>>> WDYT? >>>>>>> >>>>>>> - Brian >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>>> List Archives: >>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>>> >>>>>> _______________________________________________ >>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>> List Archives: ${hyperkitty_url} >>>>> >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Collaborative Partner - IBM >>>> Architect, JBoss EAP >>>> WildFly Project Lead >>>> He/Him/His >>>> >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>> List Archives: ${hyperkitty_url} >>> >> >> >> -- >> Brian Stansberry >> Collaborative Partner - IBM >> Architect, JBoss EAP >> WildFly Project Lead >> He/Him/His >> _______________________________________________ >> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >> List Archives: ${hyperkitty_url} >> > -- Brian Stansberry Collaborative Partner - IBM Architect, JBoss EAP WildFly Project Lead He/Him/His