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

"Base build" link for first build of branch project

      The first build of a branch project should have a UI link like Previous Build but pointing to the build on the project corresponding to the base branch (such as master for Git) which its SCM revision links to. Should use SCMSource.parentHeads; major SCM plugins needs to implement this API. When present, the base build should be used as a baseline for determining the SCM changelog, so that a user can see the changes made in the SCM commit initiating a branch. An API should also be introduced to core so that plugins such as junit can use this backlink rather than previousBuild for purposes of comparing test results; the same could be true of static analysis, code coverage, etc.

      Merely changing Run.getPreviousBuild to return a build from another Job is unsafe; many plugins may assume that the Job pairs match, or that getNextBuild is the inverse operation, etc. Perhaps we need an API addition to Run such as

      /**
       * Gets the previous build to be used for purposes of comparison of SCM commits, test results, and other reports.
       * If {@link #getPreviousBuild} is not null, that should be returned.
       * Otherwise, this may instead return a build of a {@link Job} of the same type representing a base branch from which this branch was forked.
       */
      public @CheckForNull RunT getPreviousLogicalBuild() {
          return getPreviousBuild();
      }
      

      which would most closely preserve existing semantics: build-to-build comparisons.

      Additionally/alternately:

      /**
       * Gets a build to be used for purposes of comparison of SCM commits, test results, and other reports.
       * By default, {@link #getPreviousBuild}.
       * For a job representing a branch forked from a base branch, this should return the build of the branch point.
       * Branch points may change as a base branch is manually remerged into a feature branch.
       * And jobs may be automatically building against the proposed merge of a branch,
       * in which case the base build is likely to be the latest build of the base branch.
       */
      public @CheckForNull RunT getBaseBuild() {
          return getPreviousBuild();
      }
      

      which would allow a plugin to display the cumulative changes from the base branch, which may be more relevant.
      (For example, in a build of a PR you probably want to know whether there are FindBugs regressions relative to the base branch, not whether the 13th commit to the PR introduced regressions relative to the 12th commit.)

          [JENKINS-33274] "Base build" link for first build of branch project

          Andrew Bayer added a comment -

          I'd say implement both - I can think of more places I'd use the base build rather than previous logical build, but the semantics of the two would be different enough that they'd probably both be useful.

          Where would these implementations live? In things like MultibranchJob?

          Andrew Bayer added a comment - I'd say implement both - I can think of more places I'd use the base build rather than previous logical build, but the semantics of the two would be different enough that they'd probably both be useful. Where would these implementations live? In things like MultibranchJob ?

          Andrew Bayer added a comment -

          This is not actually that worthwhile a feature to add, in practice, and is hairier to implement than I thought two years ago when I first looked into it, so I'm closing this as won't fix.

          Andrew Bayer added a comment - This is not actually that worthwhile a feature to add, in practice, and is hairier to implement than I thought two years ago when I first looked into it, so I'm closing this as won't fix.

          James Nord added a comment -

          can you define worthwhile?

          I would say not introducing new spotbugs issues into a build is very worthwhile.  

          given a PR build has no comparision spotbugs will treat all issues as new, which means you have to fix every single issue, or just ignore them and hope you don;t introduce new ones (when you are starting on a non greenfield project that has say 1000 spotbugs issues and you want to ratchet them down over time, or at least not allow new issues to be introduced).

           

          There are other use cases as well but that above is pretty worthwhile.  (you can s/spotbugs/checkstyle/) and there are likely many other use cases too that require this support.

          James Nord added a comment - can you define worthwhile? I would say not introducing new spotbugs issues into a build is very worthwhile.   given a PR build has no comparision spotbugs will treat all issues as new, which means you have to fix every single issue, or just ignore them and hope you don;t introduce new ones (when you are starting on a non greenfield project that has say 1000 spotbugs issues and you want to ratchet them down over time, or at least not allow new issues to be introduced).   There are other use cases as well but that above is pretty worthwhile.  (you can s/spotbugs/checkstyle/) and there are likely many other use cases too that require this support.

          Andrew Bayer added a comment -

          Reopening at teilo's request, but I don't expect that we'll be working on this at any time in the foreseeable future.

          Andrew Bayer added a comment - Reopening at teilo 's request, but I don't expect that we'll be working on this at any time in the foreseeable future.

          Jesse Glick added a comment -

          Yeah the only real workaround for the example teilo gave is to use Sonar to track regressions and give up on doing it from Jenkins.

          Jesse Glick added a comment - Yeah the only real workaround for the example teilo gave is to use Sonar to track regressions and give up on doing it from Jenkins.

          Jesse Glick added a comment -

          Sounds like drulli has implemented something like this privately in warnings-ng.

          Jesse Glick added a comment - Sounds like drulli has implemented something like this privately in warnings-ng .

          Ulli Hafner added a comment - - edited

          After a long time I finally merged the results of a student's master thesis into the git-forensics-plugin. I'm not sure if it is exactly the same as requested in this issue here, but this reference build (or base build) will be now used in the warnings plugin to compute new warnings in PRs, branch builds (or builds on the same branch), see documentation for more details.

          My plan is, to add this reference build as base for delta computations in the coverage plugin as well.

          Ulli Hafner added a comment - - edited After a long time I finally merged the results of a student's master thesis into the git-forensics-plugin . I'm not sure if it is exactly the same as requested in this issue here, but this reference build (or base build) will be now used in the warnings plugin to compute new warnings in PRs, branch builds (or builds on the same branch), see documentation for more details. My plan is, to add this reference build as base for delta computations in the coverage plugin as well.

          Jesse Glick added a comment -

          https://github.com/jenkinsci/forensics-api-plugin roughly matches the goal of this issue. The idea was to provide an API which would be implemented in the likes of https://github.com/jenkinsci/git-plugin so that plugins such as warnings-ng would simply ask for metadata about things such as base builds and receive an answer if supported by the SCM plugin. The current design seems to require a user to explicitly install the git-forensics plugin and then explicitly call mineRepository, which seems unfortunate since you would expect functionality like this to be universally desirable and built in.

          Jesse Glick added a comment - https://github.com/jenkinsci/forensics-api-plugin roughly matches the goal of this issue. The idea was to provide an API which would be implemented in the likes of https://github.com/jenkinsci/git-plugin so that plugins such as warnings-ng would simply ask for metadata about things such as base builds and receive an answer if supported by the SCM plugin. The current design seems to require a user to explicitly install the git-forensics plugin and then explicitly call mineRepository , which seems unfortunate since you would expect functionality like this to be universally desirable and built in.

          Ulli Hafner added a comment -

          Yes, that would be possible next steps. Integrating that functionality into the git plugin (and corresponding API plugins) was out of scope for the limited time range of the student theses.

          Ulli Hafner added a comment - Yes, that would be possible next steps. Integrating that functionality into the git plugin (and corresponding API plugins) was out of scope for the limited time range of the student theses.

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            8 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated: