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

remoteUrls are unordered in build data JSON when multiple git repositories are configured

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Environment:
    • Similar Issues:

      Description

      When multiple Git repositories are added to the git plugin (not Multiple SCM plugin), the remoteUrls in the build data JSON are unordered (different from the order in which they were configured in the Jenkins job). This is because the remoteUrls are stored in a HashSet in BuildData.java. We can instead store them in a LinkedHashSet and preserve the order.

      This is needed so that we can associate the branch built, origin[x] (where x is the repository index) in lastBuiltRevision with the appropriate repository URL for which there is no provision right now when there are multiple repositories.

      {
      "buildsByBranchName" : {
      "origin/master" : {
      "buildNumber" : 1813,
      "buildResult" : null,
      "revision" : {
      "SHA1" : "a0b422c02d45c71ca6e5317eb3aa6026d0f4ada6",
      "branch" : [

      { "SHA1" : "a0b422c02d45c71ca6e5317eb3aa6026d0f4ada6", "name" : "origin/master" }

      ]
      }
      },
      "origin/mri" : {
      "buildNumber" : 50,
      "buildResult" : null,
      "revision" : {
      "SHA1" : "f68f612f42908af792e831613deb4b6fe43ff513",
      "branch" : [

      { "SHA1" : "f68f612f42908af792e831613deb4b6fe43ff513", "name" : "origin/mri" }

      ]
      }
      }
      },
      "lastBuiltRevision" : {
      "SHA1" : "a0b422c02d45c71ca6e5317eb3aa6026d0f4ada6",
      "branch" : [

      { "SHA1" : "a0b422c02d45c71ca6e5317eb3aa6026d0f4ada6", "name" : "origin1/master" }

      ],
      "remoteUrls" : [
      "https://github.com/repo1.git",
      "https://github.com/repo2.git",
      ]
      }

        Attachments

          Activity

          Hide
          pxk5958 Pratith Kanagaraj added a comment -

          Created pull request

          Show
          pxk5958 Pratith Kanagaraj added a comment - Created pull request
          Hide
          markewaite Mark Waite added a comment -

          Can you further explain the use case for multiple git repositories defined in a single Jenkins job? I realize that the git plugin supports it, but I don't understand how it helps you accomplish something whose result can be understood by a user.

          As far as I can tell, the git plugin code will intertwine changes from each of the repositories as it finds them, checking out the SHA1 from the repositories, building it, displaying changes, etc. I've assumed that the mental model might have been that there is a repository which might be "distant" or "less frequently updated" (some form of central repository) and there are one or more additional repositories which are generally either exact copies or pure supersets of the "distant" repository, but are more accessible to the user or to the Jenkins server.

          One example of that working model might be the Jenkins official git client plugin (https://github.com/jenkinsci/git-client-plugin) and my fork of that repository (https://github.com/MarkEWaite/git-client-plugin). I keep my fork as a superset of the official repository, so I generally can see anything on my fork that is on the official repository. Thus, I've never actually needed to have a job which references both repositories. I either want the official repository, or I want my repository with my working copies.

          Show
          markewaite Mark Waite added a comment - Can you further explain the use case for multiple git repositories defined in a single Jenkins job? I realize that the git plugin supports it, but I don't understand how it helps you accomplish something whose result can be understood by a user. As far as I can tell, the git plugin code will intertwine changes from each of the repositories as it finds them, checking out the SHA1 from the repositories, building it, displaying changes, etc. I've assumed that the mental model might have been that there is a repository which might be "distant" or "less frequently updated" (some form of central repository) and there are one or more additional repositories which are generally either exact copies or pure supersets of the "distant" repository, but are more accessible to the user or to the Jenkins server. One example of that working model might be the Jenkins official git client plugin ( https://github.com/jenkinsci/git-client-plugin ) and my fork of that repository ( https://github.com/MarkEWaite/git-client-plugin ). I keep my fork as a superset of the official repository, so I generally can see anything on my fork that is on the official repository. Thus, I've never actually needed to have a job which references both repositories. I either want the official repository, or I want my repository with my working copies.
          Hide
          pxk5958 Pratith Kanagaraj added a comment -

          I am not sure either why someone would configure multiple git repositories in the Jenkins Git plugin, but I am writing a tool which gathers information from the build data json and associates the branch information with the corresponding repository url. Since the Git plugin allows the user to configure multiple repositories, I am trying to get the tool to handle it, but the remoteUrls being unordered makes it impossible to do so unless we assume the repositories are exact copies each having the same branches. It won't work even in the case where one repository is a superset of another (it could have additional branches).

          Show
          pxk5958 Pratith Kanagaraj added a comment - I am not sure either why someone would configure multiple git repositories in the Jenkins Git plugin, but I am writing a tool which gathers information from the build data json and associates the branch information with the corresponding repository url. Since the Git plugin allows the user to configure multiple repositories, I am trying to get the tool to handle it, but the remoteUrls being unordered makes it impossible to do so unless we assume the repositories are exact copies each having the same branches. It won't work even in the case where one repository is a superset of another (it could have additional branches).

            People

            • Assignee:
              Unassigned
              Reporter:
              pxk5958 Pratith Kanagaraj
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: