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

Sounds good, Jeff. I've merged your PR. Thanks for your hard work on this! Brian On Mon, Dec 4, 2023 at 5:26 AM Jean Francois Denise <jdenise(a)redhat.com&gt; wrote: 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 -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His