Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-45047

Easy way to run integration tests in plugin repositories

      (refiling from JENKINS-41631)

      For example, I would like for a PR to workflow-cps to automatically run tests in other plugins, like workflow-cps-global-lib, with the workflow-cps dependency set to the locally built snapshot. Now for simple cases this could be done easily already with no tricks: ensure that the workflow-cps-global-lib POM defines a workflow-cps-plugin.version property, and override that (as well as jenkins.version where necessary). The trouble comes when the PR to workflow-cps is downstream of a PR to, say, workflow-api. Presumably workflow-cps-global-lib is still using an older (release) version of workflow-api, so the integration test will fail. You could make it define a workflow-api-plugin.version property too, but this could become an endless exercise in replacing every dependency version with a property, and anyway the Jenkinsfile for the workflow-cps PR would then need to be patched to explicitly request the new (timestamped!) snapshot version of workflow-api, duplicating information in pom.xml. This seems unmaintainable. I would rather run the integration test Maven build with some special option, or with some special preprocessing, that automatically updates the workflow-cps version and any transitive dependencies (ideally including the Jenkins baseline too—currently workflow-cps in fact uses a newer baseline than workflow-cps-global-lib) to the upper bounds.

          [JENKINS-45047] Easy way to run integration tests in plugin repositories

          I am copying here a comment in PR-35 because I believe this is the right place to not be lost

          I believe list of dependencies to override can be large and generate it manually can be very error prone. So I would suggest implementing a mechanism similar to GIT_ASKPASS to get the override list, this way we can implement a way to take the last versions deployed in a maven repo or the versions deployed into a running jenkins instance

          Raul Arabaolaza added a comment - I am copying here a comment in PR-35 because I believe this is the right place to not be lost I believe list of dependencies to override can be large and generate it manually can be very error prone. So I would suggest implementing a mechanism similar to GIT_ASKPASS to get the override list, this way we can implement a way to take the last versions deployed in a maven repo or the versions deployed into a running jenkins instance

          Jesse Glick added a comment -

          I would expect some other tool, like a simplified version of plugin-compat-tester, to be generating the argument mechanically.

          Jesse Glick added a comment - I would expect some other tool, like a simplified version of plugin-compat-tester , to be generating the argument mechanically.

          Fair enough for me

          Raul Arabaolaza added a comment - Fair enough for me

          Jesse Glick added a comment -

          recena points me to pom-manipulation-ext which could be useful.

          Jesse Glick added a comment - recena points me to pom-manipulation-ext  which could be useful.

          Jesse Glick added a comment -

          It also occurs to me that if we implement JENKINS-47498 some of this might be easier to handle. Needs investigation.

          Jesse Glick added a comment - It also occurs to me that if we implement  JENKINS-47498  some of this might be easier to handle. Needs investigation.

          Jesse Glick added a comment -

          if we implement JENKINS-47498 some of this might be easier to handle

          Currently the BOM uses POM properties to define versions only for plugins with tests JARs, but we can see that when this is done, the dependency tree of a plugin importing the BOM can be adjusted without touching pom.xml (just like we could already do with jenkins.version):

          kubernetes-plugin$ mvn dependency:tree | fgrep scm-api; mvn -Dscm-api-plugin.version=2.6.2 dependency:tree | fgrep scm-api
          [INFO] |  \- org.jenkins-ci.plugins:scm-api:jar:2.6.3:compile
          [INFO] +- org.jenkins-ci.plugins:scm-api:jar:tests:2.6.3:test
          [INFO] |  \- org.jenkins-ci.plugins:scm-api:jar:2.6.2:compile
          [INFO] +- org.jenkins-ci.plugins:scm-api:jar:tests:2.6.2:test
          

          Jesse Glick added a comment - if we implement JENKINS-47498 some of this might be easier to handle Currently the BOM uses POM properties to define versions only for plugins with tests JARs, but we can see that when this is done, the dependency tree of a plugin importing the BOM can be adjusted without touching pom.xml (just like we could already do with jenkins.version ): kubernetes-plugin$ mvn dependency:tree | fgrep scm-api; mvn -Dscm-api-plugin.version=2.6.2 dependency:tree | fgrep scm-api [INFO] | \- org.jenkins-ci.plugins:scm-api:jar:2.6.3:compile [INFO] +- org.jenkins-ci.plugins:scm-api:jar:tests:2.6.3:test [INFO] | \- org.jenkins-ci.plugins:scm-api:jar:2.6.2:compile [INFO] +- org.jenkins-ci.plugins:scm-api:jar:tests:2.6.2:test

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: