Updated to use current version of Horreum 0.15.x

[whitingjr]

Fixes #17 feature request.

This PR updates the plugin to use the most recent version of Horreum libraries and api.

Testing done

Used existing JUnit test cases to ensure the operations provided are functioning as expected after the version bump.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Ensure you have provided tests - that demonstrates feature works or fixes the issue
• Replace SNAPSHOT dependency with released library version

[whitingjr]

I have observed the creating of a HorreumClient object is flakey due to Connection reset exceptions. Retries have been included to solve this. In the HorreumTestClientExtension. This might still be un-reliable when running on machines that are slower. I am thinking a better solution is to attempt creating a client for a minute after the Horreum container starts.

[johnaohara]

I have observed the creating of a HorreumClient object is flakey due to Connection reset exceptions. Retries have been included to solve this. In the HorreumTestClientExtension. This might still be un-reliable when running on machines that are slower. I am thinking a better solution is to attempt creating a client for a minute after the Horreum container starts.

@whitingjr I pinged you offline, but looks like that crossed with this comment :). I will copy here;

There is a HorreumResources.waitForContainerReady() method that is used to wait until the containers are ready before progressing, you can see it used in HorreumResources.startContainers() . This scans the container log, looking for a particular string, and throws an exception after a timeout. TestContainers also has a number of different waitFor strategies for pausing execution until different conditions are met if scanning the log is not sufficient.

This method can be used to ensure the services are started before trying to instantiate the client, and remove the need for any retry logic

[whitingjr]

Thanks for pointing these out. I'll replace the retry and update the branch.

[johnaohara]

@whitingjr I have opened a PR in Horreum that removes all of the Quarkus transitive dependencies in horreum-infra-common: Hyperfoil/Horreum#2017

They are not needed and will greatly simplify the transitive dependency management of the plugin.

The main difference with this change is "quarkus.http.port" & "quarkus.http.host" need to be added to the map passed to HorreumResources.startContainers() : https://github.com/Hyperfoil/Horreum/pull/2017/files#diff-b43105658cc21b6fa970980abf2234869cdc5fed60280eae9d557a6b89ed54daR112-R116

[whitingjr]

Both properties are now added and the Quarkus transitive dependencies are no longer part of the project.

[johnaohara]

I think the tests and container services look great! I think the dependencies should be cleaned up aligned to latest LTS for Jenkins, comments are inline in POM

I have also opened this PR in Horreum to simplify the container image management: Hyperfoil/Horreum#2023

[johnaohara]

The current latest version is 4.85

[whitingjr]

There is one weakness of the test cases being separate objects. The test-suite is not able to use AfterAll annotation. It is executed for every test class which causes containers to be recycled. Docker handles shutting down running containers when the tests all cease but Podman I don't recall. Was there a reason for HorreumUploadStepTest, HorreumUploadTest, HorreumExpectStepTest, HorreumExpectTest etc ?

[whitingjr]

@johnaohara For me when running the test-suite a 2nd time establishing a HorreumClient object causes Connection reset.

$ mvn clean test;mvn test
.....
[ERROR] Errors: 
[ERROR]   HorreumExpectStepTest.testExpect:22->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[ERROR]   HorreumExpectTest.testExpectRun:22->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[ERROR]   HorreumUploadStepTest.testUpload:23->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[ERROR]   HorreumUploadStepTest.testUploadMultiple:59->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[ERROR]   HorreumUploadTest.testUpload:32->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[ERROR]   HorreumUploadTest.testUploadMultiple:55->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[INFO] 
[ERROR] Tests run: 6, Failures: 0, Errors: 6, Skipped: 0
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------

In the first execution of the test goal jenkins-for-test being unpacked for booting the Jetty server causes sufficient delay for HorreumClient to authenticate. The second test goal uses the existing unpacked directory which is quicker.
Can you recreate this issue?

[johnaohara]

There is one weakness of the test cases being separate objects. The test-suite is not able to use AfterAll annotation. It is executed for every test class which causes containers to be recycled. Docker handles shutting down running containers when the tests all cease but Podman I don't recall. Was there a reason for HorreumUploadStepTest, HorreumUploadTest, HorreumExpectStepTest, HorreumExpectTest etc ?

I don't know the answer to this question

[johnaohara]

@johnaohara For me when running the test-suite a 2nd time establishing a HorreumClient object causes Connection reset.

$ mvn clean test;mvn test
.....
[ERROR] Errors: 
[ERROR]   HorreumExpectStepTest.testExpect:22->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[ERROR]   HorreumExpectTest.testExpectRun:22->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[ERROR]   HorreumUploadStepTest.testUpload:23->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[ERROR]   HorreumUploadStepTest.testUploadMultiple:59->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[ERROR]   HorreumUploadTest.testUpload:32->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[ERROR]   HorreumUploadTest.testUploadMultiple:55->HorreumPluginTestBase.createTest:18 » Runtime java.net.SocketException: Connection reset
[INFO] 
[ERROR] Tests run: 6, Failures: 0, Errors: 6, Skipped: 0
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------

In the first execution of the test goal jenkins-for-test being unpacked for booting the Jetty server causes sufficient delay for HorreumClient to authenticate. The second test goal uses the existing unpacked directory which is quicker. Can you recreate this issue?

do we need to do this?

[whitingjr]

do we need to do this?

No, just declaring it now. Other environments may fail for the initial test goal. I was seeing this occassionally before waitForContainers call was added to ArtemisMQ and Horreum. In the situation this occurs again I am thinking that after waitForContainers has returned to add a retry loop to create a HorreumClient. Let's see if necessary.

[whitingjr]

The CI is failing the build for jdk8 and jdk11.
It seems we are too ambitious targeting 17. Unless the build pipeline is updated.
https://ci.jenkins.io/job/Plugins/job/horreum-plugin/job/PR-18/

[johnaohara]

The CI is failing the build for jdk8 and jdk11. It seems we are too ambitious targeting 17. Unless the build pipeline is updated. https://ci.jenkins.io/job/Plugins/job/horreum-plugin/job/PR-18/

the project will need to align to the minimum version that the LTS jenkins version supports

[whitingjr]

the project will need to align to the minimum version that the LTS jenkins version supports

That is 11 in plugin-pom/pom.xml for 4.85 tag.
Setting the target to 11 in horreum-plugin/pom.xml then causes this enforcer rule violation.

[INFO] --- enforcer:3.1.0:enforce (display-info) @ horreum ---
[INFO] Restricted to JDK 11 yet io.hyperfoil.tools:horreum-client:jar:0.15.1:compile contains io/hyperfoil/tools/RunServiceExtension.class targeted to JDK 17
[INFO] Restricted to JDK 11 yet io.hyperfoil.tools:horreum-api:jar:0.15.1:compile contains io/hyperfoil/tools/horreum/api/ApiIgnore.class targeted to JDK 17
[WARNING] Unknown bytecodeVersion for com.fasterxml.jackson.core:jackson-core:jar:2.17.2:compile : META-INF/versions/21/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class: got null class-file-version
[WARNING] Unknown bytecodeVersion for com.fasterxml.jackson.core:jackson-core:jar:2.17.2:compile : META-INF/versions/21/com/fasterxml/jackson/core/io/doubleparser/FastIntegerMath.class: got null class-file-version
[ERROR] Rule 3: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with message:
Found Banned Dependency: io.hyperfoil.tools:horreum-client:jar:0.15.1
Found Banned Dependency: io.hyperfoil.tools:horreum-api:jar:0.15.1

Is there any prospect of getting a JDK 11 compile targeted version for the 2 modules ?

[johnaohara]

the project will need to align to the minimum version that the LTS jenkins version supports

That is 11 in plugin-pom/pom.xml for 4.85 tag. Setting the target to 11 in horreum-plugin/pom.xml then causes this enforcer rule violation.

[INFO] --- enforcer:3.1.0:enforce (display-info) @ horreum ---
[INFO] Restricted to JDK 11 yet io.hyperfoil.tools:horreum-client:jar:0.15.1:compile contains io/hyperfoil/tools/RunServiceExtension.class targeted to JDK 17
[INFO] Restricted to JDK 11 yet io.hyperfoil.tools:horreum-api:jar:0.15.1:compile contains io/hyperfoil/tools/horreum/api/ApiIgnore.class targeted to JDK 17
[WARNING] Unknown bytecodeVersion for com.fasterxml.jackson.core:jackson-core:jar:2.17.2:compile : META-INF/versions/21/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class: got null class-file-version
[WARNING] Unknown bytecodeVersion for com.fasterxml.jackson.core:jackson-core:jar:2.17.2:compile : META-INF/versions/21/com/fasterxml/jackson/core/io/doubleparser/FastIntegerMath.class: got null class-file-version
[ERROR] Rule 3: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with message:
Found Banned Dependency: io.hyperfoil.tools:horreum-client:jar:0.15.1
Found Banned Dependency: io.hyperfoil.tools:horreum-api:jar:0.15.1

Is there any prospect of getting a JDK 11 compile targeted version for the 2 modules ?

They should be targeting 1.8, but looks like the target definition is wrong in the poms:

https://github.com/Hyperfoil/Horreum/blob/0.15/horreum-api/pom.xml#L13-L14

https://github.com/Hyperfoil/Horreum/blob/0.15/horreum-client/pom.xml#L18-L19

[johnaohara]

@whitingjr : Fix target version for horreum-api and horreum-client Hyperfoil/Horreum#2026

[whitingjr]

They should be targeting 1.8, but looks like the target definition is wrong in the poms:

https://github.com/Hyperfoil/Horreum/blob/0.15/horreum-api/pom.xml#L13-L14

https://github.com/Hyperfoil/Horreum/blob/0.15/horreum-client/pom.xml#L18-L19

Yes it seems to be targeted to 17.

$ javap -v horreum-api/target/classes/io/hyperfoil/tools/horreum/api/Version.class |grep major
  major version: 61

The effective pom reveals this for horreum-api

<maven.compiler.release>17</maven.compiler.release>
    <maven.compiler.source>8</maven.compiler.source>
    <maven.compiler.target>8</maven.compiler.target>

by adding the release property to horreum-api/pom.xml for the compiler plugin it creates the targeted version correctly.

$ javap -v horreum-api/target/classes/io/hyperfoil/tools/horreum/api/Version.class |grep major
  major version: 52

Shall I create a PR ?

[johnaohara]

A PR is already merged: Hyperfoil/Horreum#2026

[johnaohara]

@whitingjr horreum 0.15.2 has been released that includes the fix for class versions

[whitingjr]

@johnaohara I am seeing horreum-infra-common now causing an issue.

ERROR]   bad class file: /home/whitingjr/.m2/repository/io/hyperfoil/tools/horreum-infra-common/0.15.2/horreum-infra-common-0.15.2.jar(/io/hyperfoil/tools/horreum/infra/common/SelfSignedCert.class)
[ERROR]     class file has wrong version 61.0, should be 55.0

A test locally with horreum-infra-common module compiled to 11 has solved all the issues.

[johnaohara]

@johnaohara I am seeing horreum-infra-common now causing an issue.

ERROR]   bad class file: /home/whitingjr/.m2/repository/io/hyperfoil/tools/horreum-infra-common/0.15.2/horreum-infra-common-0.15.2.jar(/io/hyperfoil/tools/horreum/infra/common/SelfSignedCert.class)
[ERROR]     class file has wrong version 61.0, should be 55.0

A test locally with horreum-infra-common module compiled to 11 has solved all the issues.

Is that running the build with JDK 11? we don't need to run the build/tests with JDK 11, we can use JDK17+, but release should target jdk11

[whitingjr]

Is that running the build with JDK 11? we don't need to run the build/tests with JDK 11, we can use JDK17+, but release should target jdk11

		<maven.compiler.target>17</maven.compiler.target>
		<maven.compiler.source>17</maven.compiler.source>
		<maven.compiler.release>11</maven.compiler.release>

compiling with the build/test to 17 and release at 11 the error still occurs.

[johnaohara]

Is that running the build with JDK 11? we don't need to run the build/tests with JDK 11, we can use JDK17+, but release should target jdk11

		<maven.compiler.target>17</maven.compiler.target>
		<maven.compiler.source>17</maven.compiler.source>
		<maven.compiler.release>11</maven.compiler.release>

compiling with the build/test to 17 and release at 11 the error still occurs.

what version of the JDK are you using to build with?

[whitingjr]

Good catch. I was using 11. With 17 it is ok.

[whitingjr]

There is one weakness of the test cases being separate objects. The test-suite is not able to use AfterAll annotation. It is executed for every test class which causes containers to be recycled. Docker handles shutting down running containers when the tests all cease but Podman I don't recall. Was there a reason for HorreumUploadStepTest, HorreumUploadTest, HorreumExpectStepTest, HorreumExpectTest etc ?

I don't know the answer to this question

To get the advantage of using AfterAll annotation is there any reason not to combine these separate objects into a single object ?

[whitingjr]

@johnaohara I have updated Jenkinsfile with configuration to change the CI builds. This isn't incorporated automatically to avoid malicious changes. Is there an alternative process to reconfigure the CI ?

[johnaohara]

There is one weakness of the test cases being separate objects. The test-suite is not able to use AfterAll annotation. It is executed for every test class which causes containers to be recycled. Docker handles shutting down running containers when the tests all cease but Podman I don't recall. Was there a reason for HorreumUploadStepTest, HorreumUploadTest, HorreumExpectStepTest, HorreumExpectTest etc ?

I don't know the answer to this question

To get the advantage of using AfterAll annotation is there any reason not to combine these separate objects into a single object ?

I don't see why not

[johnaohara]

@johnaohara I have updated Jenkinsfile with configuration to change the CI builds. This isn't incorporated automatically to avoid malicious changes. Is there an alternative process to reconfigure the CI ?

I do not know how CI/CD works for this project, that is something that needs figuring out