We also have one small race condition in the PRs that would be good to plug
at some point.
When WildFly Core PRs are submitted we build these with the latest WildFly
so that the changes will hopefully not prevent a subsequent Wildfly Core
upgrade.
However when we test the WildFly PRs we don't test them against the latest
WildFly Core. Some redundant code could be moved from WildFly Core after
it's CI passes, code could then be added to WildFly that depends on this
removed code and will also pass as it only tests against the last Wildfly
Core tag.
Regards,
Darran Lofthouse.
On Tue, Oct 29, 2019 at 1:46 AM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
I'd like to add jobs to the automatic testing of PRs to run the
testsuite
using slimmed installations provisioned by Galleon. But, we already run a
lot of jobs for each PR, enough so that our CI can overburdened during busy
times around deadlines. So I don't want to just add jobs. Instead I also
propose to drop the Windows + JDK 8 jobs.
Galleon Testing
During our work on WildFly 18 I added the ability to run portions of the
WildFly and WildFly Core testsuites with the tests executing against
slimmed server installations provisioned by Galleon instead of against the
complete installations normally used. The point of that was to get test
coverage of those slimmed installations.
Currently we have nightly jobs that run the testsuite this way.[1] As we
continue to evolve our set of Galleon layers, e.g. adding layers for
MicroProfile specs, I want to be sure we catch problems before PRs get
merged.
To run tests locally this way you pass -Dts.layers as an arg to maven.
Dropping Windows JDK 8 Jobs
If we'd drop something in order to free up resources for these Galleon
jobs, the Windows JDK 8 ones seem a good choice. We'd still run PRs against
Windows JDK 11, and we'd still run PRs against Linux JDK 8. I can't recall
any situation where CI found a regression that was specific to the
Windows + JDK 8 combination.
When CI gets overloaded during rush times, it's the Windows jobs that are
most problematic. The Windows jobs take longer because the storage drives
they use are slower. Plus we have fewer Windows agents. The effect is
during a rush, overall CI for PRs ends up taking hours longer while we wait
for Windows agents to come free and then run the job.
We'd still run nightly jobs with Windows + JDK 8 so in the off chance
there's a problem it would get noticed that way.
Specifics
For PRs against wildfly/wildfly I'd add a job equivalent to
https://ci.wildfly.org/viewType.html?buildTypeId=WF_GalleonLinuxJdk11 and
then drop
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequestW...
For PRs against wildfly/wildfly-core I'd add jobs equivalent to
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_GalleonLinux...
and
https://ci.wildfly.org/viewType.html?buildTypeId=WF_GalleonLinuxJdk8
and then drop
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequestW...
Any thoughts on this?
Best regards,
Brian
[1] See
https://ci.wildfly.org/viewType.html?buildTypeId=WF_GalleonLinuxJdk11
https://ci.wildfly.org/viewType.html?buildTypeId=WF_GalleonLinuxJdk8
https://ci.wildfly.org/viewType.html?buildTypeId=WF_GalleonWindowsJdk11
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_GalleonLinux...
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_GalleonLinux...
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev