[JENKINS-43795] Fix not existing Jenkins Test Harness version used

[varyvol]

JENKINS-43795

Some plugins are using jenkins.version to set the jenkins-test-harness.version, which can cause problems when overriding the Jenkins version in PCT as not all versions has a correspondent JTH version.

@reviewbybees esp. @andresrc @kwhetstone @jglick @raul-arabaolaza

[varyvol]

I know using RELEASE is not always appropriate but since this is done in case there is already a failure, I don't think it's a bad thing to use the latest released version.

Anyway any suggestion is more than welcome!

[raul-arabaolaza]

Maybe instead of modifying the pom we can use the jenkins.test-harness.version property?

[raul-arabaolaza]

After private talk with @varyvol 🐝

[varyvol]

To clarify in case someone could have the same doubt: that would not fix the issue in case the plugin explicitly had the dependency without using jenkins-test-harness.version property.

<dependency>
    <artifactId>jenkins-test-harness</artifactId>
    <version>${jenkins.version}</version>
</dependency>

[ghost]

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

[recena]

@reviewbybees done

[kwhetstone]

I'd like if this could be caught before hitting an exception. For example, using a preexecution hook to check the jenkins.test.harness version and assign the old coreCoordinates version. That would at least keep the test-harness-version at the level the plugin expects.

[varyvol]

@kwhetstone I examined that direction, but how can I know that specific JTH version does not exist? I would need to call an extra command as dependency:resolve for example, so that's why I preferred to use the execution one.

What do you mean with the level the plugin expects?

[kwhetstone]

I'm operating under the assumption that the plugin is able to compile, which should have already happened at preexecution hook time. Maven is already being called in a few different areas; I don't think it'll hurt to call it again. If you really don't want to call it again, and since you're already in MavenPom, I'd add a condition to change only if the version contains "${}" as well as including it within the TransformPom hook.

[jglick]

Some plugins are using jenkins.version to set the jenkins-test-harness.version

Can you give an example? Why not just fix those plugins?

[varyvol]

@jglick dashboard-view 2.9.10 or wikitext 3.7 for example.

@kwhetstone hurting is subjective, but executing one extra call per plugin is quite a big amount of extra time for a complete PCT I think. That's why I thought in doing it just in case of failure. Regarding the conditions:

• The version is not always declared in the POM itself, but in the parent one.
• What do you think that should be included within the hook?

[daniel-beck]

wikitext 3.7

Closed-source commercial plugins should not inform development of Jenkins project supporting infrastructure like PCT.

[jglick]

As of jenkinsci/dashboard-view-plugin#38 dashboard-view just has

<jenkins.version>1.554.1</jenkins.version>

which is invalid. It should also specify

<jenkins-test-harness.version>1.554.1</jenkins-test-harness.version>

as JTH 2.x is only compatible with 1.580.1+.

[varyvol]

Seems like the correct approach would be to analyse and fix the affected plugins. Closing this.