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

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

      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"
          }
        ],
      

          [JENKINS-52747] Jenkins REST API - Cannot determine source SCM when using multiple scms in Pipeline

          Mark R added a comment - - edited

          markewaite 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.

          Mark R added a comment - - edited markewaite 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.

          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.

          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.

          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.

          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.

          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.

          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.

          Daniel Beck added a comment -

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

          Daniel Beck added a comment - Right, which is why SCM browsers have this problem in Subversion Plugin.

          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`?

          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`?

            Unassigned Unassigned
            mrichar2 Mark R
            Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: