• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • scm-api-plugin
    • None

      I suggest to add getParent method to SCMRevision. An example for the usage would be: Computing the new warnings relative to the parent commit. To be able to do that one needs to query the scm what the parent commit is.

          [JENKINS-21007] Add method to get parent revision

          There are a number of issues with such an API enhancement:

          1. There are going to be SCM implementations that cannot resolve such a concept (e.g. CVS for one)

          2. What you are trying to get to is the previous relevant build... which with the multi-branch project type is almost always the previous build on the branch... so JENKINS-13056 is actually solved by multi-branch project type.

          3. The previous commit may not have a build associated with it... so then the API would need to give you a means to keep walking up previous commits... which need not be a single path

          However I will see if there is something that can be added to resolve such concepts even if they are flawed

          Stephen Connolly added a comment - There are a number of issues with such an API enhancement: 1. There are going to be SCM implementations that cannot resolve such a concept (e.g. CVS for one) 2. What you are trying to get to is the previous relevant build... which with the multi-branch project type is almost always the previous build on the branch... so JENKINS-13056 is actually solved by multi-branch project type. 3. The previous commit may not have a build associated with it... so then the API would need to give you a means to keep walking up previous commits... which need not be a single path However I will see if there is something that can be added to resolve such concepts even if they are flawed

          Roland Schulz added a comment -
          1. True. The API should allow to return undefined. In the case of analysis-core it could fall back to use the current approach to take the last build.
          2. We use Gerrit for Code Review. It uses the single-patch review workflow (a commit is amended for revisions) rather than the github pull request workflow (branch with fixup). Thus even with multi-branch projects the previous branch would be an earlier revision of the commit not the parent commit. If we were using the pull-workflow, I'd like to see the warnings relative to the point where the feature branch split of the main branch. Thus a API to query that point might be nice too (but not needed by us and outside the scope of this issue).
          3. For us it is guaranteed to have a build associated. Thus it would be OK if the API returned "undefined" in that case. But it might be best if it returned the first parent given that this is the convention for git.

          Roland Schulz added a comment - True. The API should allow to return undefined. In the case of analysis-core it could fall back to use the current approach to take the last build. We use Gerrit for Code Review. It uses the single-patch review workflow (a commit is amended for revisions) rather than the github pull request workflow (branch with fixup). Thus even with multi-branch projects the previous branch would be an earlier revision of the commit not the parent commit. If we were using the pull-workflow, I'd like to see the warnings relative to the point where the feature branch split of the main branch. Thus a API to query that point might be nice too (but not needed by us and outside the scope of this issue). For us it is guaranteed to have a build associated. Thus it would be OK if the API returned "undefined" in that case. But it might be best if it returned the first parent given that this is the convention for git.

          Roland Schulz added a comment -

          Is there anything I can do to help get this added?

          Roland Schulz added a comment - Is there anything I can do to help get this added?

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          src/main/java/jenkins/scm/api/SCMSource.java
          http://jenkins-ci.org/commit/scm-api-plugin/dfd212743862b9d1f7a12255723f8358bbb1bf78
          Log:
          [FIXED JENKINS-21007] Add a mechanism to get parent revision.

          • As looking up parent revisions is potentially an operation that involves remote server round trips and we do not want SCMRevision storing the entire parent tree, adding this as a method on SCMSource.
          • The methods take a TaskListener and throws IOE and InterruptedE to alert consumers of the potential cost and remoting implications in looking up the parent(s)
          • Default implementation returns empty collections to prevent NPE checks

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/java/jenkins/scm/api/SCMSource.java http://jenkins-ci.org/commit/scm-api-plugin/dfd212743862b9d1f7a12255723f8358bbb1bf78 Log: [FIXED JENKINS-21007] Add a mechanism to get parent revision. As looking up parent revisions is potentially an operation that involves remote server round trips and we do not want SCMRevision storing the entire parent tree, adding this as a method on SCMSource. The methods take a TaskListener and throws IOE and InterruptedE to alert consumers of the potential cost and remoting implications in looking up the parent(s) Default implementation returns empty collections to prevent NPE checks

          Can we get a release with this soon so that SCM plugin implementations can start using it?

          Sebastian Schuberth added a comment - Can we get a release with this soon so that SCM plugin implementations can start using it?

            Unassigned Unassigned
            rschulz Roland Schulz
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: