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

Include verify lifecycle to calculate the more relevant build for "Build whenever a SNAPSHOT dependency is built" when there is more than one upstream candidate

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: maven-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      Currently the upstream candidate resolution mechanism for "Build whenever a SNAPSHOT dependency is built" only considers Maven install and deploy lifecycle when there is more than one possible upstream build for the same artifact. In this case the name tiebreaker kicks in, which then determines the upstream build comparing by the job name. This is a reproducible behaviour but doesn't cater for the following situation as then the "wrong" build is selected depending on your naming strategy.

      If you want to split your job into two steps where the first step verifies that your maven project compiles and all test are successful and in the second step one then upload the new artefacts to your remote repository (if the first step works fine) this works fine if you run the first step with "mvn clean verify" and the second step with "mvn deploy" and there is no other upstream candidate. It doesn't work when there are other possible candidates (e.g. a static code analysis build of the same artefact) as then the tiebreaker kicks in and the the "wrong" build is selected (see above).

      Example
      Artefact A has the following two builds

      • A_1 (Static code analysis, which only compiles)
      • A_2 (CI, step1: mvn clean verify, step2: mvn deploy)

      Artifact B depends on artifact A
      There should be an automatic upstream build from B to A_2 and not A_1.
      With the current implementation, A_1 would be considered as upstream candidate as it is preferred by the name sorting tie breaker

      In order to make the "Build whenever a SNAPSHOT dependency is built" feature working for the above situation the algorithm to determine the upstream build should not only consider the install and deploy lifecycle phase, but also the verify phase in preference over the name sorting tie breaker.

        Attachments

          Activity

          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Christian Galsterer
          Path:
          src/main/java/hudson/maven/MavenModule.java
          src/test/java/hudson/maven/MavenSnapshotTriggerTest.java
          http://jenkins-ci.org/commit/maven-plugin/f8d2b8499231b13be418d96907d3d52dc3951954
          Log:
          JENKINS-21014 include verify in upstream candidate calculation

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christian Galsterer Path: src/main/java/hudson/maven/MavenModule.java src/test/java/hudson/maven/MavenSnapshotTriggerTest.java http://jenkins-ci.org/commit/maven-plugin/f8d2b8499231b13be418d96907d3d52dc3951954 Log: JENKINS-21014 include verify in upstream candidate calculation
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Christian Galsterer
          Path:
          src/test/java/hudson/maven/MavenSnapshotTriggerTest.java
          http://jenkins-ci.org/commit/maven-plugin/9687602edf2ae8ee82a6a0810ee7007d8d86226f
          Log:
          JENKINS-21014 include verify in upstream candidate calculation

          • changed test to make sure that dependencies for test projects are available in repository
          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christian Galsterer Path: src/test/java/hudson/maven/MavenSnapshotTriggerTest.java http://jenkins-ci.org/commit/maven-plugin/9687602edf2ae8ee82a6a0810ee7007d8d86226f Log: JENKINS-21014 include verify in upstream candidate calculation changed test to make sure that dependencies for test projects are available in repository
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Christoph Kutzinski
          Path:
          src/main/java/hudson/maven/MavenModule.java
          src/test/java/hudson/maven/MavenSnapshotTriggerTest.java
          http://jenkins-ci.org/commit/maven-plugin/9a6885cc87a33505b5083337eb61731ec3803f67
          Log:
          Merge pull request #19 from christiangalsterer/master

          JENKINS-21014 include verify in upstream candidate calculation

          Compare: https://github.com/jenkinsci/maven-plugin/compare/0a22e26f66bd...9a6885cc87a3

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christoph Kutzinski Path: src/main/java/hudson/maven/MavenModule.java src/test/java/hudson/maven/MavenSnapshotTriggerTest.java http://jenkins-ci.org/commit/maven-plugin/9a6885cc87a33505b5083337eb61731ec3803f67 Log: Merge pull request #19 from christiangalsterer/master JENKINS-21014 include verify in upstream candidate calculation Compare: https://github.com/jenkinsci/maven-plugin/compare/0a22e26f66bd...9a6885cc87a3
          Hide
          kutzi kutzi added a comment -

          Just for the record:

          • the use case you describe is exactly covered by the 'deploy artifacts' checkbox (don't know if that's the name in the UI from the top of my head) for Jenkins maven builds. However, I had some bad experience with this in the past (didn't work always as expected) and others are generally thinking that thie kind of Jenkins 'magic' on top of Maven is bad (e.g. Stephen Connolly . So your use case is surely a valid one.
          • in time we might include the full standard Maven lifecycle into the dependency calculation and priorise later lifecycle entries higher than previous one. Originally, I've implemented this only because the previous solution seemed completely 'random' and having any kind of predictability was better than that
          Show
          kutzi kutzi added a comment - Just for the record: the use case you describe is exactly covered by the 'deploy artifacts' checkbox (don't know if that's the name in the UI from the top of my head) for Jenkins maven builds. However, I had some bad experience with this in the past (didn't work always as expected) and others are generally thinking that thie kind of Jenkins 'magic' on top of Maven is bad (e.g. Stephen Connolly . So your use case is surely a valid one. in time we might include the full standard Maven lifecycle into the dependency calculation and priorise later lifecycle entries higher than previous one. Originally, I've implemented this only because the previous solution seemed completely 'random' and having any kind of predictability was better than that
          Hide
          bondolo Mike Duigou added a comment - - edited

          In our environment we frequently have multiple projects building the same artifacts. Most of these projects are either smoketest builds or builds for the code review validation (gerrit). We want only the projects which run off vcs updates and install artifacts to be used for dependency tracking. The availability of new artifacts is the reasonable trigger for downstream builds, no? The result of this change is that one of several projects which are building a particular set of artifacts being chosen as upstream. For our purposes this is very wrong–only projects publishing artifacts should be considered as upstream candidates.

          Show
          bondolo Mike Duigou added a comment - - edited In our environment we frequently have multiple projects building the same artifacts. Most of these projects are either smoketest builds or builds for the code review validation (gerrit). We want only the projects which run off vcs updates and install artifacts to be used for dependency tracking. The availability of new artifacts is the reasonable trigger for downstream builds, no? The result of this change is that one of several projects which are building a particular set of artifacts being chosen as upstream. For our purposes this is very wrong–only projects publishing artifacts should be considered as upstream candidates.

            People

            • Assignee:
              Unassigned
              Reporter:
              christiangalsterer Christian Galsterer
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: