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

    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

          christiangalsterer Christian Galsterer created issue -
          christiangalsterer Christian Galsterer made changes -
          Field Original Value New Value
          Summary Calculate Maven dependency graph also in verify lifecycle to deploy to local remote repository only when maven verify is succesfull and to allow proper working of "Build whenever a SNAPSHOT dependency is built" Include verify lifecycle to calculate the more relevant build for "Build whenever a SNAPSHOT dependency is built"
          Description Currently the dependency graph for "Build whenever a SNAPSHOT dependency is built" maven jobs works only for Maven install and deploy lifecycle.

          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 currently works of you run the first step with mvn clean install but not with clean verify. The problem with that when your build fails is (e.g. compilation problems, broken tests) that one has a set of artefacts in your local repository which is incomplete and in the worst case also incompatible as some parts already new and same parts are old and they are not compatible, e.g. by an API change.

          So solve this the artefacts shall only be deployed to the local and remote depository when the verify phase was successful. In order to make the "Build whenever a SNAPSHOT dependency is built" feature working, the dependency graph needs to be created not only for the install and verify lifecycle phase, but already for the verify phase.

          Please find attached a patch which contains these changes.

          If you think the patch is correct, please let me know and I create a proper hit pull request.
          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. In this case the 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 "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).

          In order to make the "Build whenever a SNAPSHOT dependency is built" feature working for the above sitatuation the algorithm to determine the upstream build should not only consider the install and deploy lifecycle phase, but also the verify phase.
          christiangalsterer Christian Galsterer made changes -
          Component/s core [ 15593 ]
          christiangalsterer Christian Galsterer made changes -
          Summary Include verify lifecycle to calculate the more relevant build for "Build whenever a SNAPSHOT dependency is built" Include verify lifecycle to calculate the more relevant build for "Build whenever a SNAPSHOT dependency is built" when there are more than one candidate
          christiangalsterer Christian Galsterer made changes -
          Summary Include verify lifecycle to calculate the more relevant build for "Build whenever a SNAPSHOT dependency is built" when there are more than one candidate 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
          christiangalsterer Christian Galsterer made changes -
          Assignee Jesse Glick [ jglick ]
          christiangalsterer Christian Galsterer made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          jglick Jesse Glick made changes -
          Assignee Jesse Glick [ jglick ]
          christiangalsterer Christian Galsterer made changes -
          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. In this case the 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 "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).

          In order to make the "Build whenever a SNAPSHOT dependency is built" feature working for the above sitatuation the algorithm to determine the upstream build should not only consider the install and deploy lifecycle phase, but also the verify phase.
          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 "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
          Artifact A has the following two builds
          - A_1 (CI, verify->deploy)
          - A_2 (Static code analysis, which only compiles)

          Artifact B depends on artifact
          There should be an automatic upstream build from B to A_1 and not A_2.

          In order to make the "Build whenever a SNAPSHOT dependency is built" feature working for the above sitatuation the algorithm to determine the upstream build should not only consider the install and deploy lifecycle phase, but also the verify phase.
          christiangalsterer Christian Galsterer made changes -
          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 "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
          Artifact A has the following two builds
          - A_1 (CI, verify->deploy)
          - A_2 (Static code analysis, which only compiles)

          Artifact B depends on artifact
          There should be an automatic upstream build from B to A_1 and not A_2.

          In order to make the "Build whenever a SNAPSHOT dependency is built" feature working for the above sitatuation the algorithm to determine the upstream build should not only consider the install and deploy lifecycle phase, but also the verify phase.
          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.
          kutzi kutzi made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 152855 ] JNJira + In-Review [ 194372 ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved: