Quantcast

[JIRA] Created: (JENKINS-9168) "git clone" should add --progress

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[JIRA] Created: (JENKINS-9168) "git clone" should add --progress

JIRA noreply@jenkins-ci.org
"git clone" should add --progress
---------------------------------

                 Key: JENKINS-9168
                 URL: http://issues.jenkins-ci.org/browse/JENKINS-9168
             Project: Jenkins
          Issue Type: Bug
          Components: git
            Reporter: Kohsuke Kawaguchi
            Assignee: abayer


When cloning a large repository over HTTP, the git server goes quiet for quite some time, busy computing a pack file. Normally, Apache is configured such that a prolonged inactivity in a socket will trigger a shutdown. So what the end user sees is that after a while, "git clone" fails by the unexpected connection reset by the server.

If the user tries the same command from the shell, Git silently adds the --progress option (see the quote from the man page.) This keeps the socket chatty enough to avoid a shutdown from Apache.

{noformat}
--progress
    Progress status is reported on the standard error stream by default when it is attached to a terminal,
    unless -q is specified. This flag forces progress status even if the standard error stream is not
    directed to a terminal.
{noformat}

So the unsuspecting users would end up concluding that Jenkins is broken.

Even worse, normally the server is owned by a different person, which makes it difficult to tweak the Apache setting. Besides, there are legitimate reasons why Apache needs to shutdown idle connections (for example to avoid DoS attack.)

So to improve the user experience, I think the best course of action is for the Git plugin to add the --progress option to the "git clone" command. We don't need to report the git clone output unless it fails, so this doesn't clutter the output, and in this way Jenkins would Just Work (TM).



--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[JIRA] Commented: (JENKINS-9168) "git clone" should add --progress

JIRA noreply@jenkins-ci.org

    [ http://issues.jenkins-ci.org/browse/JENKINS-9168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147240#comment-147240 ]

Kohsuke Kawaguchi commented on JENKINS-9168:
--------------------------------------------

I should clarify that the current behaviour of "git clone" is that it never reports its output, even in the case of a failure.

> "git clone" should add --progress
> ---------------------------------
>
>                 Key: JENKINS-9168
>                 URL: http://issues.jenkins-ci.org/browse/JENKINS-9168
>             Project: Jenkins
>          Issue Type: Bug
>          Components: git
>            Reporter: Kohsuke Kawaguchi
>            Assignee: abayer
>
> When cloning a large repository over HTTP, the git server goes quiet for quite some time, busy computing a pack file. Normally, Apache is configured such that a prolonged inactivity in a socket will trigger a shutdown. So what the end user sees is that after a while, "git clone" fails by the unexpected connection reset by the server.
> If the user tries the same command from the shell, Git silently adds the --progress option (see the quote from the man page.) This keeps the socket chatty enough to avoid a shutdown from Apache.
> {noformat}
> --progress
>     Progress status is reported on the standard error stream by default when it is attached to a terminal,
>     unless -q is specified. This flag forces progress status even if the standard error stream is not
>     directed to a terminal.
> {noformat}
> So the unsuspecting users would end up concluding that Jenkins is broken.
> Even worse, normally the server is owned by a different person, which makes it difficult to tweak the Apache setting. Besides, there are legitimate reasons why Apache needs to shutdown idle connections (for example to avoid DoS attack.)
> So to improve the user experience, I think the best course of action is for the Git plugin to add the --progress option to the "git clone" command. We don't need to report the git clone output unless it fails, so this doesn't clutter the output, and in this way Jenkins would Just Work (TM).

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[JIRA] Commented: (JENKINS-9168) "git clone" should add --progress

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

    [ http://issues.jenkins-ci.org/browse/JENKINS-9168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147246#comment-147246 ]

Harmeek Jhutty commented on JENKINS-9168:
-----------------------------------------

Yes, adding the '--progress' argument in the clone method of GITApi.java resolved the issue. Secondly, I noticed the Git clone fails when GIT_TRACE is enabled with this error:
FATAL: Invalid id: setup: git_dir: .git
java.lang.IllegalArgumentException: Invalid id: setup: git_dir: .git
        at org.spearce.jgit.lib.ObjectId.fromString(ObjectId.java:230)
        at hudson.plugins.git.GitAPI.revList(GitAPI.java:850)

It's failing because with GIT_TRACE enabled extra arguments are being printed and the BufferedReader is passing an incorrect argument i.e. setup: git_dir: .git to the org.spearce.jgit.lib.ObjectId.fromString method instead of passing the 40-digit commit id.
 hudson.plugins.git.GitAPI.revList(GitAPI.java:850 should handle the parsing of strings in a more smarter way irrespective of whether GIT_TRACE is enabled or not.


> "git clone" should add --progress
> ---------------------------------
>
>                 Key: JENKINS-9168
>                 URL: http://issues.jenkins-ci.org/browse/JENKINS-9168
>             Project: Jenkins
>          Issue Type: Bug
>          Components: git
>            Reporter: Kohsuke Kawaguchi
>            Assignee: abayer
>
> When cloning a large repository over HTTP, the git server goes quiet for quite some time, busy computing a pack file. Normally, Apache is configured such that a prolonged inactivity in a socket will trigger a shutdown. So what the end user sees is that after a while, "git clone" fails by the unexpected connection reset by the server.
> If the user tries the same command from the shell, Git silently adds the --progress option (see the quote from the man page.) This keeps the socket chatty enough to avoid a shutdown from Apache.
> {noformat}
> --progress
>     Progress status is reported on the standard error stream by default when it is attached to a terminal,
>     unless -q is specified. This flag forces progress status even if the standard error stream is not
>     directed to a terminal.
> {noformat}
> So the unsuspecting users would end up concluding that Jenkins is broken.
> Even worse, normally the server is owned by a different person, which makes it difficult to tweak the Apache setting. Besides, there are legitimate reasons why Apache needs to shutdown idle connections (for example to avoid DoS attack.)
> So to improve the user experience, I think the best course of action is for the Git plugin to add the --progress option to the "git clone" command. We don't need to report the git clone output unless it fails, so this doesn't clutter the output, and in this way Jenkins would Just Work (TM).

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[JIRA] Resolved: (JENKINS-9168) "git clone" should add --progress

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

     [ http://issues.jenkins-ci.org/browse/JENKINS-9168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

scm_issue_link resolved JENKINS-9168.
-------------------------------------

    Resolution: Fixed

> "git clone" should add --progress
> ---------------------------------
>
>                 Key: JENKINS-9168
>                 URL: http://issues.jenkins-ci.org/browse/JENKINS-9168
>             Project: Jenkins
>          Issue Type: Bug
>          Components: git
>            Reporter: Kohsuke Kawaguchi
>            Assignee: abayer
>
> When cloning a large repository over HTTP, the git server goes quiet for quite some time, busy computing a pack file. Normally, Apache is configured such that a prolonged inactivity in a socket will trigger a shutdown. So what the end user sees is that after a while, "git clone" fails by the unexpected connection reset by the server.
> If the user tries the same command from the shell, Git silently adds the --progress option (see the quote from the man page.) This keeps the socket chatty enough to avoid a shutdown from Apache.
> {noformat}
> --progress
>     Progress status is reported on the standard error stream by default when it is attached to a terminal,
>     unless -q is specified. This flag forces progress status even if the standard error stream is not
>     directed to a terminal.
> {noformat}
> So the unsuspecting users would end up concluding that Jenkins is broken.
> Even worse, normally the server is owned by a different person, which makes it difficult to tweak the Apache setting. Besides, there are legitimate reasons why Apache needs to shutdown idle connections (for example to avoid DoS attack.)
> So to improve the user experience, I think the best course of action is for the Git plugin to add the --progress option to the "git clone" command. We don't need to report the git clone output unless it fails, so this doesn't clutter the output, and in this way Jenkins would Just Work (TM).

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[JIRA] Commented: (JENKINS-9168) "git clone" should add --progress

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

    [ http://issues.jenkins-ci.org/browse/JENKINS-9168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147787#comment-147787 ]

scm_issue_link commented on JENKINS-9168:
-----------------------------------------

Code changed in jenkins
User: Andrew Bayer
Path:
 src/main/java/hudson/plugins/git/GitAPI.java
http://jenkins-ci.org/commit/git-plugin/aa753c3b736d7e3759b9a7aeeec2636592dd92d0
Log:
[FIXED JENKINS-9168] Added --progress to git clone.





> "git clone" should add --progress
> ---------------------------------
>
>                 Key: JENKINS-9168
>                 URL: http://issues.jenkins-ci.org/browse/JENKINS-9168
>             Project: Jenkins
>          Issue Type: Bug
>          Components: git
>            Reporter: Kohsuke Kawaguchi
>            Assignee: abayer
>
> When cloning a large repository over HTTP, the git server goes quiet for quite some time, busy computing a pack file. Normally, Apache is configured such that a prolonged inactivity in a socket will trigger a shutdown. So what the end user sees is that after a while, "git clone" fails by the unexpected connection reset by the server.
> If the user tries the same command from the shell, Git silently adds the --progress option (see the quote from the man page.) This keeps the socket chatty enough to avoid a shutdown from Apache.
> {noformat}
> --progress
>     Progress status is reported on the standard error stream by default when it is attached to a terminal,
>     unless -q is specified. This flag forces progress status even if the standard error stream is not
>     directed to a terminal.
> {noformat}
> So the unsuspecting users would end up concluding that Jenkins is broken.
> Even worse, normally the server is owned by a different person, which makes it difficult to tweak the Apache setting. Besides, there are legitimate reasons why Apache needs to shutdown idle connections (for example to avoid DoS attack.)
> So to improve the user experience, I think the best course of action is for the Git plugin to add the --progress option to the "git clone" command. We don't need to report the git clone output unless it fails, so this doesn't clutter the output, and in this way Jenkins would Just Work (TM).

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[JIRA] Commented: (JENKINS-9168) "git clone" should add --progress

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

    [ http://issues.jenkins-ci.org/browse/JENKINS-9168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147788#comment-147788 ]

dogfood commented on JENKINS-9168:
----------------------------------

Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_git-plugin #116|http://ci.jenkins-ci.org/job/plugins_git-plugin/116/]
     [FIXED JENKINS-9168] Added --progress to git clone.

Andrew Bayer : [aa753c3b736d7e3759b9a7aeeec2636592dd92d0|https://github.com/jenkinsci/git-plugin/commit/aa753c3b736d7e3759b9a7aeeec2636592dd92d0]
Files :
* src/main/java/hudson/plugins/git/GitAPI.java


> "git clone" should add --progress
> ---------------------------------
>
>                 Key: JENKINS-9168
>                 URL: http://issues.jenkins-ci.org/browse/JENKINS-9168
>             Project: Jenkins
>          Issue Type: Bug
>          Components: git
>            Reporter: Kohsuke Kawaguchi
>            Assignee: abayer
>
> When cloning a large repository over HTTP, the git server goes quiet for quite some time, busy computing a pack file. Normally, Apache is configured such that a prolonged inactivity in a socket will trigger a shutdown. So what the end user sees is that after a while, "git clone" fails by the unexpected connection reset by the server.
> If the user tries the same command from the shell, Git silently adds the --progress option (see the quote from the man page.) This keeps the socket chatty enough to avoid a shutdown from Apache.
> {noformat}
> --progress
>     Progress status is reported on the standard error stream by default when it is attached to a terminal,
>     unless -q is specified. This flag forces progress status even if the standard error stream is not
>     directed to a terminal.
> {noformat}
> So the unsuspecting users would end up concluding that Jenkins is broken.
> Even worse, normally the server is owned by a different person, which makes it difficult to tweak the Apache setting. Besides, there are legitimate reasons why Apache needs to shutdown idle connections (for example to avoid DoS attack.)
> So to improve the user experience, I think the best course of action is for the Git plugin to add the --progress option to the "git clone" command. We don't need to report the git clone output unless it fails, so this doesn't clutter the output, and in this way Jenkins would Just Work (TM).

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[JIRA] [git] (JENKINS-9168) "git clone" should add --progress

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org
Mark Waite closed Bug JENKINS-9168 as Fixed
Change By: Mark Waite (29/Aug/14 6:57 PM)
Status: Resolved Closed
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Previous Thread Next Thread
Loading...