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

1 view
Skip to first unread message

teilo@java.net (JIRA)

unread,
Aug 6, 2015, 12:26:02 PM8/6/15
to jenkinsc...@googlegroups.com
James Nord created an issue
 
Jenkins / Bug JENKINS-29840
when workflow uses multiple git repos the "git build data" and "tags" become next to useless.
Issue Type: Bug Bug
Assignee: Nicolas De Loof
Attachments: 2015-08-06_17h15_16.png
Components: git-plugin, workflow-plugin
Created: 06/Aug/15 4:25 PM
Environment: Jenkins 1.609.1
Workflow 1.9-beta-1
git 2.4.0
git-client 1.18.0
Priority: Minor Minor
Reporter: James Nord

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: 'g...@github.com:jenkinsci/git-client-plugin.git' 
  git url: 'g...@github.com:jenkinsci/git-plugin.git' 
  git url: 'g...@github.com:jenkinsci/github-plugin.git' 
// just add more random repos to get the picture...
}
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

jglick@cloudbees.com (JIRA)

unread,
Aug 12, 2015, 5:25:01 PM8/12/15
to jenkinsc...@googlegroups.com
Jesse Glick resolved as Duplicate
Change By: Jesse Glick
Status: Open Resolved
Resolution: Duplicate

andrew.bayer@gmail.com (JIRA)

unread,
Dec 11, 2015, 10:16:02 AM12/11/15
to jenkinsc...@googlegroups.com
Andrew Bayer reopened an issue
 

So this isn't actually a dupe of JENKINS-29326 - it's a separate symptom masked by that JIRA.
Change By: Andrew Bayer
Resolution: Duplicate
Status: Resolved Reopened
Assignee: Nicolas De Loof Andrew Bayer

andrew.bayer@gmail.com (JIRA)

unread,
Dec 11, 2015, 10:17:04 AM12/11/15
to jenkinsc...@googlegroups.com
Andrew Bayer updated an issue
Change By: Andrew Bayer
Labels: community-bee

andrew.bayer@gmail.com (JIRA)

unread,
Dec 11, 2015, 10:17:06 AM12/11/15
to jenkinsc...@googlegroups.com
Andrew Bayer commented on Bug JENKINS-29840
 
Re: when workflow uses multiple git repos the "git build data" and "tags" become next to useless.

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@gmail.com (JIRA)

unread,
Dec 11, 2015, 11:09:01 AM12/11/15
to jenkinsc...@googlegroups.com

Jesse Glick, 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@gmail.com (JIRA)

unread,
Dec 11, 2015, 11:30:01 AM12/11/15
to jenkinsc...@googlegroups.com

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.

jglick@cloudbees.com (JIRA)

unread,
Dec 11, 2015, 11:48:01 AM12/11/15
to jenkinsc...@googlegroups.com

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.

andrew.bayer@gmail.com (JIRA)

unread,
Dec 11, 2015, 12:12:02 PM12/11/15
to jenkinsc...@googlegroups.com

Annoyingly, BuildData can have multiple sha1s, thanks to the dementedness of the git plugin. =) And yeah, I didn't like the idea of scmName, just was observing that it was already being used. I can easily distinguish between the BuildData, but I don't know what to use to distinguish them as URLs (my first tests were using hashCode(), which works fine but is not exactly aesthetically pleasing in the URL) and I really have no idea how to distinguish the display names without it getting ridiculously long. I could use toString stuff from BuildData and Build, but...well, repo URL(s), branch(es) and hash(es) gets pretty long pretty quick, probably too long for the sidebar link display name.

andrew.bayer@gmail.com (JIRA)

unread,
Dec 12, 2015, 12:50:02 PM12/12/15
to jenkinsc...@googlegroups.com

So - I think hashCode() for the URL actually does make sense. It's more or less guaranteed to be unique here - I'd like to use the sha1, but then I have to put in some weird logic to deal with cases where there are multiple remote repos pulling into one local repo and merging and things just get odd.

For the display name (both on the BuildData and GitTagAction), I'm thinking something like this logic:

  • If scmName is defined, use that. Nice and simple.
  • Otherwise, if there's only one remote repository/branch spec combo, use the repo name (i.e., just just the whatever.git, not full URL) and branch spec (everything after the first slash, that is, so the branch name or pattern excluding the remote).
  • Lastly, if there are multiple remote repositories, forget it, we just punt and put a "#1", "#2", whatever there. In cases where there could be multiple BuildData added, it'll be really, really, really rare that there are multiple remote repositories in a single BuildData, I think, so I'm willing to compromise on the aesthetics in those edge cases in order to get a win on the other far more common cases.

Actually, maybe don't bother for GitTagAction and instead change the text to say "Tag the above" or something along those lines, since it's always going to be the next Action after its associated BuildData, which will present more information. And I'm leaning towards rewording "Git Build Data" to something shorter if possible, so that the additional text we'll be throwing on the display text has some room before the word wrapping/line count goes bonkers.

Thoughts?

martin.danjou14@gmail.com (JIRA)

unread,
Dec 13, 2015, 10:59:01 AM12/13/15
to jenkinsc...@googlegroups.com

I do not know what scmName comes out as, for example, does say just "git", or "svn"? In this case I agree that it is not sufficient, esp when you see two SHA1s on the build page (the one from the "Workflow from SCM", and the other from the actual project being built).

Showing the repo name works for me, at least this way my users will be able to tell which is which between the "Workflow from SCM" repo and their project repo. Hopefully this case does not fall into the 3rd scenario (numbering them without showing a name). Also I would never want my users to be able to tag the "Workflow from SCM" repository, they should only be allowed to tag their project.

andrew.bayer@gmail.com (JIRA)

unread,
Dec 13, 2015, 11:22:01 AM12/13/15
to jenkinsc...@googlegroups.com

In the Additional Behaviors section of the git plugin config, you can specify a "Custom SCM Name" - this is particularly useful historically when using the Multiple SCMs plugin, e.g., in part because it makes the UI a bit nicer as things are now. So while most cases aren't going to have this set, I'd still like to use that as the first possibility when it is set, since it gives more user control, etc.

The third scenario is for Weird Git Usage Cases - i.e., when in the normal Git SCM UI, you're specifying multiple remote repositories but not multiple clones...it's a weird feature, IMO, but it is there, so I need to factor it in. Pretty much every Workflow scenario wouldn't fit that - each "git" Workflow DSL step call would result in a separate BuildData with a single remote repo/repo name, so falling into the second scenario.

I'm...not sure how to deal with the conditional tagging rights thing. That's an interesting question, but not an easy answer. I don't see a smooth way to do that.

martin.danjou14@gmail.com (JIRA)

unread,
Dec 13, 2015, 1:42:01 PM12/13/15
to jenkinsc...@googlegroups.com

Thanks for the clarifications regarding scmName, it makes sense to me to use it when it is set. Since the user sets it, the user can control what shows up on the build page.

Regarding the fact that the "Workflow from SCM" also produces links on the build page, could those specific links be made visible only to administrators? At the minimum, a link like "Tag my repo", which can change the "Workflow from SCM" repo, should not be visible to an ordinary user. In any case, I think this is a different problem than the one this Jira intended to solve.

jglick@cloudbees.com (JIRA)

unread,
Dec 15, 2015, 10:41:03 AM12/15/15
to jenkinsc...@googlegroups.com
Jesse Glick started work on Bug JENKINS-29840
 
Change By: Jesse Glick
Status: Open In Progress

jglick@cloudbees.com (JIRA)

unread,
Dec 15, 2015, 10:41:03 AM12/15/15
to jenkinsc...@googlegroups.com
Change By: Jesse Glick
Status: Reopened Open

martin.danjou14@gmail.com (JIRA)

unread,
Jan 4, 2016, 11:01:03 AM1/4/16
to jenkinsc...@googlegroups.com
 
Re: when workflow uses multiple git repos the "git build data" and "tags" become next to useless.

Since Git Plugin 2.4.1 the scmName is shown when set, but the Workflow does not expose the Additional Behaviors section in the code snippet, so I do not know how to configure the Custom SCM name with the git SCM step:

For example:

// Workflow code
node ('remote') {
    git url: 'https://github.com/allegro/axion-release-plugin.git',
        <how do I set the custom scm name?>: 'axion-release-plugin'
}

There are multiple little aspects to this problem.

jglick@cloudbees.com (JIRA)

unread,
Jan 4, 2016, 1:54:02 PM1/4/16
to jenkinsc...@googlegroups.com

Additional Behaviors and other features can be selected when using the checkout step, not the deliberately simplistic git step.

jglick@cloudbees.com (JIRA)

unread,
Aug 29, 2016, 2:10:06 PM8/29/16
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
 
Change By: Jesse Glick
Component/s: workflow-scm-step-plugin
Component/s: pipeline
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

vivek.pandey@gmail.com (JIRA)

unread,
Feb 27, 2018, 12:17:14 AM2/27/18
to jenkinsc...@googlegroups.com
Vivek Pandey updated an issue
Change By: Vivek Pandey
Sprint: Pipeline - October, Pipeline - December March 2018
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

vivek.pandey@gmail.com (JIRA)

unread,
Nov 15, 2018, 5:22:06 PM11/15/18
to jenkinsc...@googlegroups.com
Vivek Pandey updated an issue
Change By: Vivek Pandey
Labels: community-bee triaged-2018-11
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mark.earl.waite@gmail.com (JIRA)

unread,
Nov 15, 2019, 3:49:19 PM11/15/19
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
Change By: Mark Waite
Assignee: Andrew Bayer
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages