[wildfly-dev] Re: Discovery of Galleon layers in the WildFly testsuite

Thank Brian, reply inlined. On 12/1/23 18:09, Brian Stansberry wrote: Thanks, Jeff, for the detailed explanation! On Fri, Dec 1, 2023 at 9:11 AM Jean Francois Denise <jdenise(a)redhat.com&gt; wrote: > Hi, > > an heads-up that we are changing the approach when provisioning WildFly > with Galleon layers in the WildFly testsuite. > > Prior to https://github.com/wildfly/wildfly/pull/17153 (that should be > merged soon), a base layer (e.g.: cloud-server) + some decorator layers > (according to the test case) were explicitly set to provision servers used > by tests. So the actual set of required Galleon layers was generally larger > than what the test actually requires. > > Thanks to the WildFly Glow <https://github.com/wildfly/wildfly-glow> > Arquillian Maven plugin, we are now scanning the Arquillian deployments > (prior to the test execution) to discover the required Galleon layers. A > provisioning.xml file containing the discovered layers is generated and > used by the WildFly Maven plugin to actually provision the test server. > > In order to validate that what the scanning has discovered is expected, > you can configure the wildfly-glow-arquillian-plugin maven plugin to > contain the element <expected-discovery>. For example: > > <expected-discovery>[cdi, ee-integration, ejb, ejb-lite, > elytron-oidc-client, naming, > servlet]==>ee-core-profile-server,ejb,elytron-oidc-client</expected-discovery> > I could ask this on the PR but I'll ask here as it relates to a general usage question. I notice we are running the 'scan' goal in test-compile: https://github.com/wildfly/wildfly/pull/17153/files#diff-100b3a1c5caf72ad... Can it run in 'test'? How would it relate to standard maven build control idioms like -fae and -DskipTests? We currently check the expected layers in all cases. I am going to skip the checks if skipTests or maven.test.skip are set. -fae works as expected. If a scan fails, the maven execution of this module stops and next module is executed. The failures are reported at the end.

I'm not asking so much about your PR and the WF build; e.g. if a scan failure failed our build that's not terrible. (Maybe it is; we'll see!) But I could see how app developers could want to use this as just another test of their app. They've at some point come up with provisioning instructions, and they want to test that changes to the app don't invalidate those instructions. But they want to be able to control this like any other test execution. The left part of the arrow contains the list of the discovered layers > according to the scanning. The right part is what will get provisioned. > Composed of a base layer (always ee-core-profile-server) + a list of the > discovered layers that has been cleaned-up to avoid to include dependencies. > > BTW: The PR https://github.com/wildfly/wildfly/pull/17153 contains a lot > of examples of WildFly Glow scanning executions that you can use as > starting-point. > > In case the test depends on some not discoverable features, you have the > ability to explicitly add add-ons to enrich the set of provisioned layers > (using the <add-ons> configuration element). > > In addition, it can happen that some errors are identified by WildFly > Glow. Some need to be fixed, some could be fine in the context of the > tests. Errors that are fine in the context of the test can be ignored using > the <expected-errors> element. > > Known WildFly Glow discovered errors: > > * jakarta.naming.Context or InitialContext lookup: In case some lookup is > present in the test code that could hide the usage of a layer not > discovered. You can configure the plugin with <add-layers-for-jndi> to add > the layers that are required (if any) and hidden. > > * ambiguous resource injection: An un-typed resource injection could hide > a required layer. You can configure the plugin with <add-layers-for-jndi> > to list the layers that are required (if any) and hidden. > > * an add-on of the messaging family is expected by the messaging-activemq > layer. One of embedded or remoting messaging add-on is required. > > * unbound datasources error: <name of ds>: A datasource is expected but > not found in the deployment. That is generally an error to ignore, the test > itself should add the datasource during the setup. > > * no default datasource found error: It has been identified that a > default datasource is required. That can be fixed by adding the add-on > h2-database:default > > You can find more information related to WildFly Glow in its > documentation <http://docs.wildfly.org/wildfly-glow/>;. > > Thank-you. > > JF > _______________________________________________ > 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... > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His