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

when workflow uses multiple git repos the "git build data" and "tags" become next to useless.

    • Pipeline - October, Pipeline - April 2018

      if you have a workflow which uses multiple git repositories the actions and data contributed to the build by the git plugin produce almost unusable visual spam.

      The tag action does not let you know which repository you are tagging, nor does the build data tell you which repository it is that has the specified hash.

      Coupled with this you end up with 2 * the number of repos used (plus another 2 if you use workflow from SCM) actions - which simply does not scale. The actions should be refactored so there is one action that can display the data from multiple repositories / invocations and it should be clear which revision comes from which repo.

      node {
        git url: 'git@github.com:jenkinsci/git-client-plugin.git' 
        git url: 'git@github.com:jenkinsci/git-plugin.git' 
        git url: 'git@github.com:jenkinsci/github-plugin.git' 
      // just add more random repos to get the picture...
      }
      

          [JENKINS-29840] when workflow uses multiple git repos the "git build data" and "tags" become next to useless.

          James Nord created issue -
          Jesse Glick made changes -
          Link New: This issue duplicates JENKINS-29326 [ JENKINS-29326 ]
          Jesse Glick made changes -
          Resolution New: Duplicate [ 3 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

          Andrew Bayer added a comment -

          So this isn't actually a dupe of JENKINS-29326 - it's a separate symptom masked by that JIRA.

          Andrew Bayer added a comment - So this isn't actually a dupe of JENKINS-29326 - it's a separate symptom masked by that JIRA.
          Andrew Bayer made changes -
          Assignee Original: Nicolas De Loof [ ndeloof ] New: Andrew Bayer [ abayer ]
          Resolution Original: Duplicate [ 3 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]

          Andrew Bayer added a comment -

          From JENKINS-29326:

          So there is another aspect to this - with my fix, you don't get duplicate BuildData added to the build, but if you have multiple repos checked out during the build, the "Git Build Data" links are all actually the same link, which makes sense. The build page shows the multiple BuildData actions, but .../(job)/(build number)/git is just the first one. I'm honestly not sure the right way to make those distinct, though - something involving getUrlName for sure.

          Andrew Bayer added a comment - From JENKINS-29326 : So there is another aspect to this - with my fix, you don't get duplicate BuildData added to the build, but if you have multiple repos checked out during the build, the "Git Build Data" links are all actually the same link, which makes sense. The build page shows the multiple BuildData actions, but .../(job)/(build number)/git is just the first one. I'm honestly not sure the right way to make those distinct, though - something involving getUrlName for sure.
          Andrew Bayer made changes -
          Labels New: community-bee

          Andrew Bayer added a comment -

          jglick, oleg_nenashev - do either of you, by any chance, know of a case where an Action can have multiples on a single build and the sidebar links end up different? Trying to figure out an example to derive from for reworking that here.

          Andrew Bayer added a comment - jglick , oleg_nenashev - do either of you, by any chance, know of a case where an Action can have multiples on a single build and the sidebar links end up different? Trying to figure out an example to derive from for reworking that here.

          Andrew Bayer added a comment -

          Ok, figured it out - getUrlName needs to be unique for each Action. So I have to figure out a reliable and useful way to get a unique string for each BuildData and each GitTagAction, and I need to determine a way to distinguish the display names as well...if scmName is specified, that gets done already for BuildData, but if it isn't, there's no distinction, and GitTagAction switches its display name based on whether tagging has been done already.

          Andrew Bayer added a comment - Ok, figured it out - getUrlName needs to be unique for each Action . So I have to figure out a reliable and useful way to get a unique string for each BuildData and each GitTagAction , and I need to determine a way to distinguish the display names as well...if scmName is specified, that gets done already for BuildData , but if it isn't, there's no distinction, and GitTagAction switches its display name based on whether tagging has been done already.

          Jesse Glick added a comment -

          scmName is a crappy workaround. Use GitSCM.getKey() where necessary to determine whether two configurations are the same. Or if you have access to BuildData then you have a simpler and more reliable piece of information: the actual SHA-1 of the commit.

          Jesse Glick added a comment - scmName is a crappy workaround. Use GitSCM.getKey() where necessary to determine whether two configurations are the same. Or if you have access to BuildData then you have a simpler and more reliable piece of information: the actual SHA-1 of the commit.

            Unassigned Unassigned
            teilo James Nord
            Votes:
            26 Vote for this issue
            Watchers:
            32 Start watching this issue

              Created:
              Updated: