Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-20543

ProvisioningConsistencyTestCase failures with s390 Semeru

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Minor Minor
    • 37.0.0.Final
    • None
    • Test Suite
    • None

      https://ci.wildfly.org/viewType.html?buildTypeId=WF_MainNightlyJobs_StandardLinuxS390SemeruJdk17

      https://ci.wildfly.org/viewType.html?buildTypeId=WF_MainNightlyJobs_StandardLinuxS390SemeruJdk21

      Both are showing recurring ProvisioningConsistencyTestCase failures with this symptom:

      java.lang.AssertionError: [dist file for /store/work/tc-work/d4136b1fd6efe7b3/ee-dist/target/wildfly-36.0.0.Final-SNAPSHOT/bin/client/jboss-client.jar has an unexpected length: 24027938 not 24028544, dist file for /store/work/tc-work/d4136b1fd6efe7b3/ee-dist/target/wildfly-36.0.0.Final-SNAPSHOT/bin/client/jboss-cli-client.jar has an unexpected length: 11016557 not 11016845, dist file for /store/work/tc-work/d4136b1fd6efe7b3/ee-dist/target/wildfly-36.0.0.Final-SNAPSHOT/bin/wildfly-elytron-tool.jar has an unexpected length: 80753 not 80749]
      	at org.junit.Assert.fail(Assert.java:89)
      	at org.wildfly.test.distribution.validation.ProvisioningConsistencyBaseTest.testInstallationEquivalence(ProvisioningConsistencyBaseTest.java:156)
      

      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 the jboss-client.jar and jboss-cli-client.jar are shaded jars created at provisioning time via that task.

      jdenise@redhat.com FYI.

              jdenise@redhat.com Jean Francois Denise
              bstansbe@redhat.com Brian Stansberry
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: