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

Jenkins REST API - Cannot determine source SCM when using multiple scms in Pipeline

    Details

    • Similar Issues:

      Description

      When a build has commits from multiple repositories (such as when using a pipeline job) it isn't possible to determine what repository (remote URL) a commit came from using the REST API.

      The issue is neither a ChangeLogSet or a ChangeLogSet.Entry has any knowledge of the SCM it came from. Thus when the bean is exported the API does not have that information. If there are multiple repositories in play it becomes impossible to know the repository a commit came from.

      I believe the solution would be to add knowledge of the SCM (or even just remote URL) to the ChangeLogSet when the list of changeset(s) is built (WorkflowRun.getChangeSets() for Jenkinsfiles and AbstractBuild.getChangeSet() for Freestyle jobs). This would allow a consumer of the API to know which SCMs a commit came from.

      For example, given a Jenkinsfile job with 4 git repos that only had commit changes for 2 of them the API response might look like the json below. Observe that it there is no way to know which remote a changeset came from. See the attached file for more details.

      http://myjenkins:8080/view/folder/job/foo/job/master/17/api/json?pretty=true

      "changeSets" : [
          {
            "_class" : "hudson.plugins.git.GitChangeSetList",
            "items" : [
              {
                "_class" : "hudson.plugins.git.GitChangeSet",
                "affectedPaths" : [
                  ...
                ],
                "commitId" : "4da434ef7fccefa9a0922ee49556319efc923973",
                ...
              },
              {
                "_class" : "hudson.plugins.git.GitChangeSet",
                "affectedPaths" : [
                  ...
                ],
                "commitId" : "b23c08d558786dd73ef5ba20737c485a6406a9f4",
                ...
              }
            ],
            "kind" : "git"
          },
          {
            "_class" : "hudson.plugins.git.GitChangeSetList",
            "items" : [
              {
                "_class" : "hudson.plugins.git.GitChangeSet",
                "affectedPaths" : [
                  ...
                ],
                "commitId" : "86593c915bf11f17d477072895a5afd2e5cb733f",
                ...
              }
            ],
            "kind" : "git"
          }
        ],
      

        Attachments

          Activity

          Hide
          mrichar2 Mark R added a comment - - edited

          Mark Waite This is a shortcoming in the Jenkins REST API not returning enough information. I'm not referring to getting the information within the job when it is running. I updated the title and description to clarify.

          Show
          mrichar2 Mark R added a comment - - edited Mark Waite This is a shortcoming in the Jenkins REST API not returning enough information. I'm not referring to getting the information within the job when it is running. I updated the title and description to clarify.
          Hide
          mrichar2 Mark R added a comment - - edited

          When the list of changeset(s) is built (WorkflowRun.getChangeSets() for Jenkinsfiles and AbstractBuild.getChangeSet() for Freestyle jobs) all that would be needed is to attach information about the SCM to each ChangeLogSet that is returned.

          Show
          mrichar2 Mark R added a comment - - edited When the list of changeset(s) is built ( WorkflowRun.getChangeSets() for Jenkinsfiles and AbstractBuild.getChangeSet() for Freestyle jobs) all that would be needed is to attach information about the SCM to each ChangeLogSet that is returned.
          Hide
          danielbeck Daniel Beck added a comment -

          Notably, AFAIUI, the same problem exists with one SCM, multiple repos, like e.g. Subversion supports, so the problem might well be more common than described here. When I wrote https://github.com/jenkinsci/tortoisesvn-browser-plugin I had to guess based on the revision in the changelog. All built-in repo browsers fail at this.

          Show
          danielbeck Daniel Beck added a comment - Notably, AFAIUI, the same problem exists with one SCM, multiple repos, like e.g. Subversion supports, so the problem might well be more common than described here. When I wrote https://github.com/jenkinsci/tortoisesvn-browser-plugin I had to guess based on the revision in the changelog. All built-in repo browsers fail at this.
          Hide
          jay_hendren jay hendren added a comment -

          I think it's also worth mentioning that it's not only the REST API that has this shortcoming, but also the Java/Groovy API.

          Show
          jay_hendren jay hendren added a comment - I think it's also worth mentioning that it's not only the REST API that has this shortcoming, but also the Java/Groovy API.
          Hide
          danielbeck Daniel Beck added a comment -

          Right, which is why SCM browsers have this problem in Subversion Plugin.

          Show
          danielbeck Daniel Beck added a comment - Right, which is why SCM browsers have this problem in Subversion Plugin.
          Hide
          crossan007 Charles Crossan added a comment -

          I'm encountering this issue as well.   I just discovered this Jira ticket after posting on StackOverflow: https://devops.stackexchange.com/questions/3798/determine-the-url-for-a-scm-trigger-from-inside-the-build/8496#8496

           

          Based on the description above, it would seem that all historic SCM `GitChangeSetList` instances in old jobs would be missing the upstream `repoUrl` even if this issue were to be resolved in a future version?  Or would there be some mechanism by which old `GitChangeSetList` instances could be linked with an SCM `browser`?

          Show
          crossan007 Charles Crossan added a comment - I'm encountering this issue as well.   I just discovered this Jira ticket after posting on StackOverflow: https://devops.stackexchange.com/questions/3798/determine-the-url-for-a-scm-trigger-from-inside-the-build/8496#8496   Based on the description above, it would seem that all historic SCM `GitChangeSetList` instances in old jobs would be missing the upstream `repoUrl` even if this issue were to be resolved in a future version?  Or would there be some mechanism by which old `GitChangeSetList` instances could be linked with an SCM `browser`?

            People

            • Assignee:
              Unassigned
              Reporter:
              mrichar2 Mark R
            • Votes:
              2 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: