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

Easy way to run integration tests in plugin repositories

    Details

    • Similar Issues:

      Description

      (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.

        Attachments

          Issue Links

            Activity

            Hide
            rarabaolaza 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

            Show
            rarabaolaza 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
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            rarabaolaza Raul Arabaolaza added a comment -

            Fair enough for me

            Show
            rarabaolaza Raul Arabaolaza added a comment - Fair enough for me
            Hide
            jglick Jesse Glick added a comment -

            Manuel Recena Soto points me to pom-manipulation-ext which could be useful.

            Show
            jglick Jesse Glick added a comment - Manuel Recena Soto points me to pom-manipulation-ext  which could be useful.
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            jglick 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
            
            Show
            jglick 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

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                jglick Jesse Glick
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: