[WFCORE-6755] Move the org.wildfly.security:wildfly-elytron-dynamic-ssl artifact into its own module #5947

Skyllarr · 2024-04-09T13:54:07Z

https://issues.redhat.com/browse/WFCORE-6755

wildfly-ci · 2024-04-09T13:59:59Z

Core -> Full Integration Build 13459 outcome was FAILURE using a merge of 7f57b63
Summary: Exit code 1 (Step: Build full with JDK 17 (Maven)) Build time: 00:04:55

wildfly-ci · 2024-04-09T14:01:41Z

Core -> WildFly Preview Integration Build 13519 outcome was FAILURE using a merge of 7f57b63
Summary: Exit code 1 (Step: Build & test full (Maven)) Build time: 00:06:37

wildfly-ci · 2024-04-09T14:02:33Z

Core -> Full Integration Build 13718 outcome was FAILURE using a merge of 7f57b63
Summary: Exit code 1 (Step: Build full with JDK 17 (Maven)) Build time: 00:07:28

yersan · 2024-04-10T09:57:51Z

Hello @Skyllarr , we need a WFLY Jira/PR in place to fix the layers test case in WildFly. We can merge this WFCORE PR as the latest PR for this release, but we need the Jira/PR to run manually the integration Job.

An alternative is to hack the WidlFly LayersTestCase to ignore this specific layer, and then remove the hack once Core is bumped on WildFly

wildfly-ci · 2024-04-10T12:24:46Z

Core -> WildFly Preview Integration Build 13527 outcome was FAILURE using a merge of a218264
Summary: Tests failed: 1, passed: 4975, ignored: 86 Build time: 02:49:56

Failed tests

org.jboss.as.test.layers.expansion.LayersTestCase.testLayersModuleUse: java.lang.AssertionError: Some expected modules have not been provisioned in test-all-layers: org.wildfly.security.elytron-dynamic-ssl
	at org.jboss.as.test.layers.LayersTest.testLayersModuleUse(LayersTest.java:172)
	at org.jboss.as.test.shared.LayersTestBase.testLayersModuleUse(LayersTestBase.java:409)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

Skyllarr · 2024-04-10T13:04:58Z

Hello @Skyllarr , we need a WFLY Jira/PR in place to fix the layers test case in WildFly. We can merge this WFCORE PR as the latest PR for this release, but we need the Jira/PR to run manually the integration Job.

An alternative is to hack the WidlFly LayersTestCase to ignore this specific layer, and then remove the hack once Core is bumped on WildFly

Thanks @yersan , I've created https://issues.redhat.com/browse/WFLY-19223 and I'm working on fixing the test

yersan · 2024-04-11T08:04:30Z

Integration Jobs:

https://ci.wildfly.org/buildConfiguration/WF_WildFlyCoreIntegrationExperiments/429188 (Galleon Integration)
https://ci.wildfly.org/buildConfiguration/WF_WildFlyCoreIntegrationExperiments/429204 (WildFly Preview Integration JDK 17)

yersan

@Skyllarr The integration test failed, if we really don't want to provision this module when we are trimming the server, the fix in WildFly Full should be to add it at https://github.com/wildfly/wildfly/blob/a53eba00bde46400befd053c4a104e7107da0071/testsuite/shared/src/main/java/org/jboss/as/test/shared/LayersTestBase.java#L45 instead.

But I have doubts whether this is want we want to do, I would expect this feature also when we are trimming the server but we are including the Elytron layer

...esources/modules/system/layers/base/org/wildfly/security/elytron-dynamic-ssl/main/module.xml

yersan · 2024-04-11T11:06:42Z

testsuite/layers/src/test/java/org/jboss/as/test/layers/LayersTestCase.java

@@ -26,6 +26,7 @@ public class LayersTestCase {
        // No patching modules in layers
        "org.jboss.as.patching",
        "org.jboss.as.patching.cli",
+        "org.wildfly.security.elytron-dynamic-ssl"


If the intention is to leave the usage of this module when the server is trimmed including the Elytron layer, this change could be fine but we need to add a comment above it explaining the reason why this module is not provided when using layers.

I have doubts we want that, it looks like the intention could be to also provide the capabilities of the dynamic SSL context even when we are using the Elytron layer. If that's the case, I guess you have to register the module with

wildfly-core/controller/src/main/java/org/jboss/as/controller/ResourceDefinition.java

Line 127 in d5456e9

default void registerAdditionalRuntimePackages(final ManagementResourceRegistration resourceRegistration) {

, which in turns should be invoked depending on the current Stability level

should be invoked depending on the current Stability level

or as a different way to see it, be invoked when the management resource associated with this Elytron Dynamic SSL is being registered, which I would assume is registered for community only stability level

@yersan yes, this module should be provided when using elytron layer and the community stability. I'll fix this, thank you!

Skyllarr · 2024-04-11T17:11:26Z

@yersan I've addressed your feedback. I closed the affiliated wildfly PR since these latest changes do not introduce a failure in wildfly testsuite. Thank you!

Skyllarr · 2024-04-11T17:11:50Z

@darranl / @fjuma Please review, thanks!

wildfly-ci · 2024-04-17T02:11:35Z

Core -> Full Integration Build 13495 outcome was UNKNOWN using a merge of f56300e
Summary: Canceled (Swabra) Build time: 02:31:31

wildfly-ci · 2024-04-17T03:15:17Z

Core -> WildFly Preview Integration Build 13556 outcome was FAILURE using a merge of f56300e
Summary: Tests failed: 1, passed: 4977, ignored: 86 Build time: 03:35:09

Failed tests

org.jboss.as.test.layers.expansion.LayersTestCase.testLayersModuleUse: java.lang.AssertionError: Some expected modules have not been provisioned in test-all-layers: org.wildfly.security.elytron-dynamic-ssl
	at org.jboss.as.test.layers.LayersTest.testLayersModuleUse(LayersTest.java:172)
	at org.jboss.as.test.shared.LayersTestBase.testLayersModuleUse(LayersTestBase.java:409)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

wildfly-ci · 2024-04-17T04:01:56Z

Core -> Full Integration Build 13757 outcome was UNKNOWN using a merge of f56300e
Summary: Canceled (Step 2/7) Build time: 04:21:51

wildfly-ci · 2024-04-17T13:40:24Z

Core -> Full Integration Build 13497 outcome was UNKNOWN using a merge of 7bf0715
Summary: Canceled (Exit code 143 (Step: Build full with JDK 17 (Maven)) (new)) Build time: 00:07:22

wildfly-ci · 2024-04-17T16:22:46Z

Core -> Full Integration Build 13498 outcome was FAILURE using a merge of 7bf0715
Summary: Tests failed: 2, passed: 4039, ignored: 51 Build time: 02:40:00

Failed tests

org.jboss.as.test.layers.base.LayersTestCase.testLayersModuleUse: java.lang.AssertionError: Some expected modules have not been provisioned in test-all-layers: org.wildfly.security.elytron-dynamic-ssl
	at org.jboss.as.test.layers.LayersTest.testLayersModuleUse(LayersTest.java:172)
	at org.jboss.as.test.shared.LayersTestBase.testLayersModuleUse(LayersTestBase.java:409)
	at org.jboss.as.test.layers.base.LayersTestCase.testLayersModuleUse(LayersTestCase.java:37)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


org.jboss.as.test.layers.expansion.LayersTestCase.testLayersModuleUse: java.lang.AssertionError: Some expected modules have not been provisioned in test-all-layers: org.wildfly.security.elytron-dynamic-ssl
	at org.jboss.as.test.layers.LayersTest.testLayersModuleUse(LayersTest.java:172)
	at org.jboss.as.test.shared.LayersTestBase.testLayersModuleUse(LayersTestBase.java:409)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

wildfly-ci · 2024-04-17T16:49:39Z

Core -> WildFly Preview Integration Build 13557 outcome was FAILURE using a merge of 7bf0715
Summary: Tests failed: 1, passed: 4976, ignored: 87 Build time: 02:46:59

Failed tests

org.jboss.as.test.layers.expansion.LayersTestCase.testLayersModuleUse: java.lang.AssertionError: Some expected modules have not been provisioned in test-all-layers: org.wildfly.security.elytron-dynamic-ssl
	at org.jboss.as.test.layers.LayersTest.testLayersModuleUse(LayersTest.java:172)
	at org.jboss.as.test.shared.LayersTestBase.testLayersModuleUse(LayersTestBase.java:409)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

yersan

In my opinion, this is completed, although we are waiting for https://issues.redhat.com/browse/WFCORE-6805 to do more testing and see if the approach is the correct one. We are waiting to have the ability to limit the available stability levels based on the provisioning stability level

yersan · 2024-04-25T10:46:39Z

In my opinion, this is completed, although we are waiting for https://issues.redhat.com/browse/WFCORE-6805 to do more testing and see if the approach is the correct one. We are waiting to have the ability to limit the available stability levels based on the provisioning stability level

Well, current failures on integration tests are not expected, so it still requires investigation into what is causing them.

Skyllarr · 2024-04-26T14:15:25Z

In my opinion, this is completed, although we are waiting for https://issues.redhat.com/browse/WFCORE-6805 to do more testing and see if the approach is the correct one. We are waiting to have the ability to limit the available stability levels based on the provisioning stability level

I see, thanks @yersan ! I will look into the integration tests failures

…sl artifact into its own module

wildfly-ci · 2024-05-01T13:08:20Z

Core -> Full Integration Build 13532 outcome was FAILURE using a merge of af6dd7c
Summary: Tests failed: 2, passed: 3954, ignored: 59 Build time: 02:03:15

Failed tests

org.jboss.as.test.layers.base.LayersTestCase.testLayersModuleUse: java.lang.AssertionError: Some expected modules have not been provisioned in test-all-layers: org.wildfly.security.elytron-dynamic-ssl
	at org.jboss.as.test.layers.LayersTest.testLayersModuleUse(LayersTest.java:172)
	at org.jboss.as.test.shared.LayersTestBase.testLayersModuleUse(LayersTestBase.java:409)
	at org.jboss.as.test.layers.base.LayersTestCase.testLayersModuleUse(LayersTestCase.java:37)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


org.jboss.as.test.layers.expansion.LayersTestCase.testLayersModuleUse: java.lang.AssertionError: Some expected modules have not been provisioned in test-all-layers: org.wildfly.security.elytron-dynamic-ssl
	at org.jboss.as.test.layers.LayersTest.testLayersModuleUse(LayersTest.java:172)
	at org.jboss.as.test.shared.LayersTestBase.testLayersModuleUse(LayersTestBase.java:409)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

wildfly-ci · 2024-05-01T13:31:18Z

Core -> WildFly Preview Integration Build 13587 outcome was FAILURE using a merge of af6dd7c
Summary: Tests failed: 1, passed: 4994, ignored: 82 Build time: 02:26:13

Failed tests

org.jboss.as.test.layers.expansion.LayersTestCase.testLayersModuleUse: java.lang.AssertionError: Some expected modules have not been provisioned in test-all-layers: org.wildfly.security.elytron-dynamic-ssl
	at org.jboss.as.test.layers.LayersTest.testLayersModuleUse(LayersTest.java:172)
	at org.jboss.as.test.shared.LayersTestBase.testLayersModuleUse(LayersTestBase.java:409)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

Skyllarr · 2024-05-01T14:52:10Z

In my opinion, this is completed, although we are waiting for https://issues.redhat.com/browse/WFCORE-6805 to do more testing and see if the approach is the correct one. We are waiting to have the ability to limit the available stability levels based on the provisioning stability level

Well, current failures on integration tests are not expected, so it still requires investigation into what is causing them.

@yersan This PR should solve the issues with LayersTestCase wildfly/wildfly#17862 , locally it works for me

yersan · 2024-05-03T10:40:03Z

@Skyllarr There is a relevant error on the "Galleon Linux - JDK 11 (Pull Request)" Job:

java.lang.AssertionError: Some expected modules have not been provisioned in test-all-layers: org.wildfly.security.elytron-dynamic-ssl
  at org.junit.Assert.fail(Assert.java:89)
  at org.jboss.as.test.layers.LayersTest.testLayersModuleUse(LayersTest.java:172)
  at org.jboss.as.test.layers.LayersTestCase.testLayersModuleUse(LayersTestCase.java:111)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.base/java.lang.reflect.Method.invoke(Method.java:566)

I don't know exactly what is causing that, but the problem seems to be that elytron galleon layer is not provisioning the org.wildfly.security.elytron-dynamic-ssl

I've just taken a look but I don't see the root cause, since Elytron subsystem is advertising to Galleon the requirement of this package at https://github.com/wildfly/wildfly-core/pull/5947/files#diff-263be4d2ab5108fc2de76f44766487703d2444e7bcc70bac0aaa4be6a27a9089R114

@jfdenise Could you shed some light on this?

I've just done a quick test and, although the relevant package is correctly advertised with resourceRegistration.registerAdditionalRuntimePackages(RuntimePackageDependency.required(dependencyPackageName)), the expected set of provisioned packages for the Elytron galleon layer does not includes the org.wildfly.security.elytron-dynamic-ssl package name.

What we are missing here?

yersan · 2024-05-13T09:08:18Z

@jfdenise a friendly reminder, do you have any points about why Galleon does not provision the advertised package?

yersan · 2024-06-10T08:59:49Z

Hello @jfdenise this is still a blocker for us, could you provide your feedback about why Galleon is not working as we expect for this case? I am not sure if we are missing something here.

bstansberry · 2024-06-13T17:22:45Z

@Skyllarr There is a relevant error on the "Galleon Linux - JDK 11 (Pull Request)" Job:
java.lang.AssertionError: Some expected modules have not been provisioned in test-all-layers: org.wildfly.security.elytron-dynamic-ssl
  at org.junit.Assert.fail(Assert.java:89)
  at org.jboss.as.test.layers.LayersTest.testLayersModuleUse(LayersTest.java:172)
  at org.jboss.as.test.layers.LayersTestCase.testLayersModuleUse(LayersTestCase.java:111)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.base/java.lang.reflect.Method.invoke(Method.java:566)
I don't know exactly what is causing that, but the problem seems to be that elytron galleon layer is not provisioning the org.wildfly.security.elytron-dynamic-ssl

I've just taken a look but I don't see the root cause, since Elytron subsystem is advertising to Galleon the requirement of this package at https://github.com/wildfly/wildfly-core/pull/5947/files#diff-263be4d2ab5108fc2de76f44766487703d2444e7bcc70bac0aaa4be6a27a9089R114

@jfdenise Could you shed some light on this?

I've just done a quick test and, although the relevant package is correctly advertised with resourceRegistration.registerAdditionalRuntimePackages(RuntimePackageDependency.required(dependencyPackageName)), the expected set of provisioned packages for the Elytron galleon layer does not includes the org.wildfly.security.elytron-dynamic-ssl package name.

What we are missing here?

@yersan Is the resource part of the elytron subsystem configuration provided by the 'elytron' layer? Or, less likely, some other layer included in the test-all-layers set?

I haven't looked at what the 'elytron' layer configures but I suspect it doesn't add this resource.

The resourceRegistration.registerAdditionalRuntimePackages stuff is only relevant if the resource is part of the configuration. It doesn't tell Galleon to provision things that are not in the configuration just in case they user might want to add them later.

If that's the case the solution is to tell LayersTestCase not to expect the module to be provisioned.

yersan · 2024-06-27T12:29:21Z

@bstansberry

Is the resource part of the elytron subsystem configuration provided by the 'elytron' layer? Or, less likely, some other layer included in the test-all-layers set?

The resource is just a subresource of the standard Elytron subsystem, however, it is distributed via an optional module, which, in turn, is never provisioned by any other Galleon Layer.

The resourceRegistration.registerAdditionalRuntimePackages stuff is only relevant if the resource is part of the configuration. It doesn't tell Galleon to provision things that are not in the configuration just in case they user might want to add them later.

Ok, thanks for clarifying it. Now I understand the issue is that since not configured by the Elytron subsystem when it is provisioned as a Galleon layer, then the source code will never advertise it requires such a package.

However, this subresource does not require any Elytron subsystem configuration, so, I don't know how it can be added to the Elytron layer as an empty feature.

I can only think of adding it as a required package for the Elytron layer at:

wildfly-core/core-feature-pack/galleon-common/src/main/resources/layers/standalone/elytron/layer-spec.xml

Lines 16 to 20 in bb0806b

    
           <packages> 
        
               <!-- required by default configuration--> 
        
               <package name="org.wildfly.extension.elytron.jaas-realm"/> 
        
               <package name="org.wildfly.openssl"/> 
        
           </packages>

But not sure if that is the correct approach. It fixes the problem, since it makes it provisioned always when Elytron is configured. but not sure if that is the approach or even if we add it there, whether we would still need the resourceRegistration.registerAdditionalRuntimePackages stuff

darranl · 2024-07-09T14:42:14Z

I think to invert some of the discussions the two times we would expect that this module is NOT provisioned are:

provisioning a server that does not contain the elytron extension
provisioning a server that only supports default stability level

In all other cases this module should be present in the installation

yersan · 2024-07-10T12:47:36Z

Superseded by #6066

github-actions bot added the deps-ok Dependencies have been checked, and there are no significant changes label Apr 9, 2024

Skyllarr force-pushed the WFCORE-6755 branch from 7f57b63 to a56e71a Compare April 9, 2024 17:51

Skyllarr marked this pull request as ready for review April 9, 2024 17:54

Skyllarr force-pushed the WFCORE-6755 branch from a56e71a to a218264 Compare April 9, 2024 19:54

This comment was marked as outdated.

Sign in to view

yersan added the Blocker label Apr 10, 2024

yersan requested a review from fjuma April 10, 2024 09:59

Skyllarr mentioned this pull request Apr 10, 2024

[WFLY-19223] LayersTestCase should pass with new org.wildfly.security.elytron-dynamic-ssl module wildfly/wildfly#17809

Closed

Skyllarr force-pushed the WFCORE-6755 branch from a218264 to d4ad197 Compare April 11, 2024 07:58

yersan added the 24.x label Apr 11, 2024

This comment was marked as outdated.

Sign in to view

yersan requested changes Apr 11, 2024

View reviewed changes

Skyllarr force-pushed the WFCORE-6755 branch from d4ad197 to 2a37017 Compare April 11, 2024 13:17

This comment was marked as outdated.

Sign in to view

Skyllarr requested a review from darranl April 11, 2024 17:12

Skyllarr force-pushed the WFCORE-6755 branch from 8598ddb to f56300e Compare April 16, 2024 23:39

This comment was marked as outdated.

Sign in to view

Skyllarr force-pushed the WFCORE-6755 branch 2 times, most recently from bf0a659 to 7bf0715 Compare April 17, 2024 08:19

yersan removed the 24.x label Apr 17, 2024

yersan added the 25.x label Apr 22, 2024

yersan reviewed Apr 25, 2024

View reviewed changes

[WFCORE-6755] Move the org.wildfly.security:wildfly-elytron-dynamic-s…

af6dd7c

…sl artifact into its own module

Skyllarr force-pushed the WFCORE-6755 branch from 7bf0715 to af6dd7c Compare May 1, 2024 11:02

Skyllarr mentioned this pull request May 3, 2024

[WFLY-19223] LayersTestCase should pass with new org.wildfly.security.elytron-dynamic-ssl module wildfly/wildfly#17862

Closed

yersan mentioned this pull request Jul 10, 2024

[WFCORE-6755] Move the org.wildfly.security:wildfly-elytron-dynamic-ssl artifact into its own module #6066

Open

yersan closed this Jul 10, 2024

[WFCORE-6755] Move the org.wildfly.security:wildfly-elytron-dynamic-ssl artifact into its own module #5947

[WFCORE-6755] Move the org.wildfly.security:wildfly-elytron-dynamic-ssl artifact into its own module #5947

Conversation

Skyllarr commented Apr 9, 2024

wildfly-ci commented Apr 9, 2024

wildfly-ci commented Apr 9, 2024

wildfly-ci commented Apr 9, 2024

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

yersan commented Apr 10, 2024

wildfly-ci commented Apr 10, 2024

Failed tests

Skyllarr commented Apr 10, 2024

yersan commented Apr 11, 2024

This comment was marked as outdated.

This comment was marked as outdated.

yersan left a comment

Choose a reason for hiding this comment

yersan Apr 11, 2024

Choose a reason for hiding this comment

yersan Apr 11, 2024

Choose a reason for hiding this comment

Skyllarr Apr 11, 2024

Choose a reason for hiding this comment

This comment was marked as outdated.

Skyllarr commented Apr 11, 2024

Skyllarr commented Apr 11, 2024

wildfly-ci commented Apr 17, 2024

wildfly-ci commented Apr 17, 2024

Failed tests

wildfly-ci commented Apr 17, 2024

This comment was marked as outdated.

wildfly-ci commented Apr 17, 2024

wildfly-ci commented Apr 17, 2024

Failed tests

wildfly-ci commented Apr 17, 2024

Failed tests

yersan left a comment

Choose a reason for hiding this comment

yersan commented Apr 25, 2024

Skyllarr commented Apr 26, 2024

wildfly-ci commented May 1, 2024

Failed tests

wildfly-ci commented May 1, 2024

Failed tests

Skyllarr commented May 1, 2024

yersan commented May 3, 2024

yersan commented May 13, 2024

yersan commented Jun 10, 2024

bstansberry commented Jun 13, 2024

yersan commented Jun 27, 2024

darranl commented Jul 9, 2024

yersan commented Jul 10, 2024