Native support for multi-module Maven projects #488
Comments
basil
changed the title
|
https://github.com/jenkinsci/plugin-compat-tester/tree/multimodule (which I accidentally pushed to @jtnord Can you pick this up and take it across the finish line? |
👍
one test cycle per plugin? Whilst we may be able to do something like
Would we ever be in a situation where the plugins from a single repository in the war would not be aligned? Should not be the case for CloudBees' product - and I believe the tools bom is ok here to, in which case this should be ok. |
Yes.
The code I have been hacking on so far in the
One step ahead of you, mate: yes indeed, as evidenced by these errors I got in some deeper testing today: But I was able to get those errors to go away with this code in With the current prototype in the Here are the repositories that were cloned in the above run: In other words, a loop of 7 repositories rather than 27 plugins. This is probably going to cut down on compute cost. I am feeling pretty good about this design right now. 😄 |
|
To facilitate collaboration, there is now a |
|
Results doing automated testing in |
|
And with jenkinsci/configuration-as-code-plugin#2234 all the tests in |
we must never install into the local repo - that will make a mockery of the PCT as we are no longer testing against the released binaries but what we just built and installed for other plugins outside of the reactor. This is especially true where this can be run on developer machines where we may not be running a single test for a single reactor in a throwaway environment. |
|
This view could only be held by someone who has likely not tried to implement an alternative. This is not a code review, so if you feel that you could do a better job, then please push an improved version to the project branch (that also passes full |
I took a crack at this today and with some difficulty implemented most of it in jenkinsci/maven-hpi-plugin#453 and 3a5dee3f. More work needs to be done to adapt |
|
Weekly update: This project branch has passed its most rigorous automated test run yet in I am not aware of contributions during the past week from any other member(s) of the project. If this situation persists, the project will stagnate. |
|
included in 1313.v036de64e1863 |
The current code has extremely special and convoluted handling for multi-module Maven projects. Every multi-module Maven project needs a custom hook in PCT in order to work at all, and even then there are various problems. For example, consider the case of a multi-module Maven project that contains a plugin with a dependency on another plugin in the same multi-module Maven project. An example of this is Pipeline: Declarative Extension Points API, which depends on Pipeline: Model API, both of which are in the same multi-module Maven project. In this case, our current workflow requires two different invocations of PCT, one for each plugin. However, this results in PCT unnecessarily compiling both the dependent and its dependency but only executing tests for the dependent.
At a high level, this should be rewritten so that given a set of plugins, PCT collects a set of repositories containing those plugins and then invokes Maven from the root of each repository. Then we would need no special handling for multi-module Maven projects.
Implementing this should be relatively straightforward: the list of plugins provided can be transformed into a list of repositories, with the main
forloop inorg.jenkins.tools.test.PluginCompatTester#testPluginsconverted to loop over repositories rather than plugins, with the semantics oforg.jenkins.tools.test.PluginCompatTester#testPluginAgainstchanged to be "test repository against" rather than "test plugin against."However, one complication is CI callers such as
jenkinsci/bom. These callers take a megawar and list its plugins, invoking parallel runs of PCT, one for each plugin. With the change above to iterate over repositories over plugins, such consumers will want to pass in a list of all plugins that are contained in a given repository rather than passing in a single plugin. For example, to test thepipeline-model-definition-pluginrepository, consumers would want to invoke PCT with--plugins pipeline-model-api,pipeline-model-definition,pipeline-model-extensions,pipeline-stage-tags-metadata; PCT should then coalesce these into the single repositorypipeline-model-definition-plugin, do one clone, one build, and one test cycle. But how would consumers know to pass in that particular list of plugins?One solution would be a new PCT flag that, for a given megawar, prints the mapping of repositories to plugins. For example, it could have output like this:
Consumers would run PCT with this flag to determine the division of parallel branches, each line of the output being a parallel branch (one for each repository). The consumers would pass in the output of the
PLUGINScolumn as the--pluginsparameter to PCT in each branch.The text was updated successfully, but these errors were encountered: