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

Easy way to run integration tests in plugin repositories

    XMLWordPrintable

Details

    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

            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

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

            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.

            Fair enough for me

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

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

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

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

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

              Dates

                Created:
                Updated: