This is a WildFly Core report analogous to WFLY-20543, which is about an analogous test in full WildFly.

https://ci.wildfly.org/buildConfiguration/WildFlyCore_MainNightlyJobs_MainLinuxS390OpenJ917

ProvisioningConsistencyTestCase is repeatedly failing like this:

java.lang.AssertionError: [dist file for /store/work/tc-work/e9bccef30f12678d/testsuite/manualmode/target/wildfly-from-channel/bin/client/jboss-cli-client.jar has an unexpected length: 11050327 not 11050405, dist file for /store/work/tc-work/e9bccef30f12678d/testsuite/manualmode/target/wildfly-from-channel/bin/wildfly-elytron-tool.jar has an unexpected length: 80807 not 80869]
	at org.junit.Assert.fail(Assert.java:89)
	at org.jboss.as.test.manualmode.provisioning.ProvisioningConsistencyTestCase.testInstallationEquivalence(ProvisioningConsistencyTestCase.java:160)

What this test does is compare two dists:

1) the 'official' dist in the dist/target dir that's provisioned with the wildfly-maven-plugin
2) one provisioned in the testsuite dir using org.jboss.galleon:galleon-maven-plugin

The basic goal being to validate the plugins produce equivalent output.

At this point the test could perhaps be dropped – it was initially created when the official dist was produced with galleon-maven-plugin but the tool we were telling users to use was wildfly-maven-plugin. So we wanted a check to help ensure our own dist would match what our recommended plugin would produce. But now our own dist is produced with the recommended plugin.

But, still there's some value in the comparison, in case doing it flags up unexpected behavior. Perhaps this is such a case.

My instinct is the failure here is the result of some subtle behavior of the assemble-shaded-artifact Galleon task. Both wildfly-elytron-tool.jar is a shaded jar created at provisioning time via that task. The failures in full WF also involve shaded jars

jdenise@redhat.com FYI.