Plugin PCT runs should use current BOM version, not the BOM version defined by the plugin

[basil]

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 20.04.3 LTS x86_64

Reproduction steps

Run e.g. PLUGINS=mailer bash local-test.sh.

Expected Results

The PCT run should use the versions of all plugins defined in this repository.

Actual Results

Mailer defines its BOM version as 1075.v14bef33e5d7b, and the PCT run will use that BOM version when building up the test classpath, though the Jenkins WAR will be the "megawar" with the plugin versions defined in this repository.

Anything else?

No response

[jglick]

PCT has loads of problems. I think it will only update dependencies that are literally shown as <version> in pom.xml in that repo. If I found time to work on jenkinsci/maven-hpi-plugin#66 it would probably solve this sort of thing and allow PCT to be much simpler.

[basil]

I don't doubt that jenkinsci/maven-hpi-plugin#66 will solve this sort of thing in the long term. But I think getting PCT, when run from this repository, to update the version of the plugin BOM specified in the plugin's pom.xml to the code under test (i.e., the build of jenkinsci/bom that was completed in prep.sh) would eliminate most of the pain in the short to medium term.

[jglick]

Should be possible. Would need to introduce a new (repeatable) option to PCT allowing you to indicate the GAV of a BOM which it would check for an import of in the POM.

[jtnord]

Should be possible. Would need to introduce a new (repeatable) option to PCT allowing you to indicate the GAV of a BOM which it would check for an import of in the POM.

and do what with that information? just using the latest is not correct and can end up testing a combination that is too new for a combination set.

jenkinsci/bom is not the only consumer of the PCT.

[jglick]

and do what with that information?

As above, make PCT rewrite the imported BOM version to be a supplied version. So if you ran PCT with

-updateBOM io.jenkins.tools.bom:bom-2.289.x:1168.v0a_657ceb_868f,io.jenkins.tools.bom:bom-2.303.x:1168.v0a_657ceb_868f,…

(with the version number corresponding to the currently tested source tree, or 999999-SNAPSHOT if not in CI) then any

<dependency>
  <groupId>io.jenkins.tools.bom</groupId>
  <artifactId>bom-2.289.x</artifactId>
  <version>1075.v14bef33e5d7b</version>
  <scope>import</scope>
  <type>pom</type>
</dependency>

would be changed to

<dependency>
  <groupId>io.jenkins.tools.bom</groupId>
  <artifactId>bom-2.289.x</artifactId>
  <version>1168.v0a_657ceb_868f</version>
  <scope>import</scope>
  <type>pom</type>
</dependency>

Whether that is the right fix of this problem is another question. The issue title implicitly assumes a particular solution, but the actual problem is that PCT is given a -war option containing some plugin versions but these are not honored in the case of transitive dependencies, at least not those whose version is managed by the BOM. I suppose direct dependencies managed by the BOM are OK because PCT will see a <dependency> with no <version> and add one; the bug in PCT is that (AFAIK) it will not add a <dependency> for a transitive version even when it should. If I am right, this is not really limited to BOMs at all.

[jglick]

And even when you have an explicit <dependency> in the plugin POM, but it is <optional>, if it gives no <version> (allows it to be managed by a BOM) then PCT will not override it. PCT does add “synthetic” dependencies on what looks to be all transitive plugin deps (incorrectly adding them to the main <dependencies> section rather than <dependencyManagement>), so I am not sure at this point under exactly which conditions it neglects to override versions.

[jglick]

Not sure if jenkinsci/plugin-compat-tester#202 is in active use, but it does not address the issues here.

[jglick]

I wonder if jenkinsci/plugin-compat-tester#240 actually worked.