[JIRA] (JENKINS-43818) Git fetch fails when "Branch Specifier" uses a parameter in new version of the Git plugin

1 view
Skip to first unread message

samduke474@gmail.com (JIRA)

unread,
Apr 3, 2019, 6:19:04 AM4/3/19
to jenkinsc...@googlegroups.com
Sam Duke reopened an issue
 

Is there any chance this could be looked at again with a view to changing Lightweight Checkout to be able to substitute in the variables?

Our checkout is very slow so this really hurts us!

Jenkins / Bug JENKINS-43818
Git fetch fails when "Branch Specifier" uses a parameter in new version of the Git plugin
Change By: Sam Duke
Resolution: Not A Defect
Status: Closed Reopened
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

samduke474@gmail.com (JIRA)

unread,
Apr 3, 2019, 6:19:06 AM4/3/19
to jenkinsc...@googlegroups.com

samduke474@gmail.com (JIRA)

unread,
Apr 3, 2019, 6:19:06 AM4/3/19
to jenkinsc...@googlegroups.com

samduke474@gmail.com (JIRA)

unread,
Apr 3, 2019, 6:57:02 PM4/3/19
to jenkinsc...@googlegroups.com

ddigtiar@cloudbees.com (JIRA)

unread,
Apr 3, 2019, 7:42:03 PM4/3/19
to jenkinsc...@googlegroups.com

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

unread,
Apr 4, 2019, 6:18:02 AM4/4/19
to jenkinsc...@googlegroups.com

samduke474@gmail.com (JIRA)

unread,
Apr 4, 2019, 6:35:02 AM4/4/19
to jenkinsc...@googlegroups.com
Sam Duke commented on Bug JENKINS-43818
 
Re: Git fetch fails when "Branch Specifier" uses a parameter in new version of the Git plugin

Denys Digtiar Looks like Mark doesn't work on this project any more. How can I escalate this?

 

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

unread,
Apr 4, 2019, 7:23:02 AM4/4/19
to jenkinsc...@googlegroups.com

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

unread,
Apr 4, 2019, 7:27:02 AM4/4/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-43818
[~samskiter] I do work on this project during my nights and weekends.

I manage the list of issues I'm actively investigating by unassigning myself from an issue when I'm not actively investigating the issue.  I'm not actively investigating this issue.

You may be able to improve checkout performance using a reference repository or by narrowing the refspec of the repository clone or by using a shallow clone.

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

unread,
Apr 4, 2019, 7:31:02 AM4/4/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-43818
[~samskiter] I do work on this project during my nights and weekends.

I manage the list of issues I'm actively investigating by unassigning myself from an issue when I'm not actively investigating the issue.  I'm not actively investigating this issue.

You may be able to improve checkout performance using a reference repository or by narrowing the refspec of the repository clone or by using a shallow clone.   Refer to "[Git in the Large|https://youtu.be/jBGFjFc6Jf8?t=6434]" for a presentation that I created to improve git performance with large git repositories in Jenkins.

samduke474@gmail.com (JIRA)

unread,
Apr 4, 2019, 7:35:02 AM4/4/19
to jenkinsc...@googlegroups.com
Sam Duke commented on Bug JENKINS-43818

Ah apologies, I must have misread your activity feed.

We are looking into the reference repository option - is there any documentation on how this checkout method works? (does it use git alternates, for example?)

We are already doing a depth=1 clone of a specific ref (a SHA passed from gerrit) so I don't see how we can narrow it any more. Even with that ur checkout times of the pipeline groovy script is 10 minutes currently (thanks to all the other checking out it needs to do and all our actual building happens on other machines so it really should just be a few seconds to grab the groovy file and execute it.

It seems the Lightweight checkout is seriously stunted in its usability because of the limitation of not being able to expand variables. In fact in anything but the simplest setup ("please build this fixed branch / tag") I can't see how you would use it.

Is there any process to escalate this ticket?

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

unread,
Apr 4, 2019, 7:54:02 AM4/4/19
to jenkinsc...@googlegroups.com

Sure, you could escalate through one of the organizations that provides commercial support like CloudBees. If you're a CloudBees customer, you can submit a support ticket.

You could escalate it by implementing the desired capability including automated tests and submitting a pull request.

You might also be able to get dramatically faster checkout by choosing a different git provider. If your source code is hosted on GitHub or Bitbucket, you can use the matching branch source provider plugin and it will use a REST API call to read the contents of the Jenkinsfile. I believe a similar technique is also used for Gitea.

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

unread,
Apr 4, 2019, 8:10:02 AM4/4/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-43818
Sure, you could escalate through one of the organizations that provides commercial support like CloudBees.  If you're a CloudBees customer, you can submit a support ticket.

You could escalate it by implementing the desired capability including automated tests and submitting a pull request.

You might also be able to get dramatically faster checkout by choosing a different git provider.  If your source code is hosted on GitHub or Bitbucket, you can use the matching branch source provider plugin and it will use a REST API call to read the contents of the Jenkinsfile.  I believe a similar technique is also used for Gitea.


The prioritized changes that I've seen as most effective with a large repository with many branches that are mostly independent are:
# Use a reference repository to reduce network data transfer in {{git fetch}}
# Narrow the refspec when cloning the repository to only pull changes from the exact branch being built (reduce data transfer in {{git fetch}})
# Shallow clone (depth=1) to only pull most recent changes (reduce data transfer in {{git fetch}})

arun.subbaramu@gmail.com (JIRA)

unread,
Nov 19, 2019, 12:19:07 AM11/19/19
to jenkinsc...@googlegroups.com

Is the fix for this issue planned anytime soon or if the issue is not fixed how do we fix the the issue by applying this patch
[^JENKINS-14276.patch]
 
Any pointers greatly appreciated.

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

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

unread,
Nov 19, 2019, 1:18:06 AM11/19/19
to jenkinsc...@googlegroups.com

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

unread,
Nov 19, 2019, 1:20:06 AM11/19/19
to jenkinsc...@googlegroups.com
Mark Waite commented on Bug JENKINS-43818
 
Re: Git fetch fails when "Branch Specifier" uses a parameter in new version of the Git plugin

No fix is planned for this issue by me. I don't recognize your reference to JENKINS-14276.patch. Instructions for building the Git plugin are included in its CONTRIBUTING file. Instructions for building the git client plugin are included in its CONTRIBUTING file.

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

unread,
Nov 19, 2019, 1:25:07 AM11/19/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-43818
No fix is planned for this issue by me.  I don't recognize your reference to JENKINS-14276.patch.  Instructions for building the Git plugin are included in its [CONTRIBUTING|https://github.com/jenkinsci/git-plugin/blob/master/CONTRIBUTING.adoc#contributing-to-the-git-plugin] file.  Instructions for building the git client plugin are included in its [CONTRIBUTING|https://github.com/jenkinsci/git-client-plugin/blob/master/CONTRIBUTING.adoc#contributing-to-the-git-client-plugin] file.

After looking at the history of JENKINS-14276 and its related bugs, I doubt any patches from that bug or its related bugs will help with this issue.  This issue is requesting parameter expansion for pipeline jobs which use lightweight checkout to obtain the Jenkinsfile.  I doubt those changes from 2015 will help with lightweight checkout in pipelines.
Reply all
Reply to author
Forward
0 new messages