• Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Major Major
    • git-plugin
    • None

      I've set the timeout for git operations to 30 minutes, since cloning over a slow line takes longer than the default 10 minutes. Initial cloning fails with timeouts:

      Gestartet durch Benutzer
      [EnvInject] - Loading node environment variables.
      Baue in Arbeitsbereich /var/lib/jenkins/sharedspace/linux-3.18
      Cloning the remote Git repository
      Cloning repository https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
       > git init /var/lib/jenkins/sharedspace/linux-3.18/linux-3.18.y # timeout=10
      Fetching upstream changes from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
       > git --version # timeout=10
       > git -c core.askpass=true fetch --tags --progress https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git +refs/heads/*:refs/remotes/origin/*
      ERROR: Timeout after 10 minutes
      ERROR: Error cloning remote repo 'origin'
      ERROR: Error cloning remote repo 'origin'
      Finished: FAILURE
      

      I'd awaited, since I've set a timeout of 30 minutes, to not time out after 10 minutes!
      The 30 minutes timeout is then respected, but not for the first cloning operation (after cloning manually):

      Gestartet durch Benutzer
      [EnvInject] - Loading node environment variables.
      Baue in Arbeitsbereich /var/lib/jenkins/sharedspace/linux-3.18
       > git rev-parse --is-inside-work-tree # timeout=10
      Fetching changes from the remote Git repository
       > git config remote.origin.url https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git # timeout=10
      Fetching upstream changes from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
       > git --version # timeout=10
       > git -c core.askpass=true fetch --tags --progress https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git +refs/heads/*:refs/remotes/origin/*
       > git rev-parse origin/linux-3.18.y^{commit} # timeout=10
      Checking out Revision 762167f98c6aa8d47c801f8b6ac20bf30d786a4b (origin/linux-3.18.y)
       > git config core.sparsecheckout # timeout=10
       > git checkout -f 762167f98c6aa8d47c801f8b6ac20bf30d786a4b # {color:#d04437}timeout=30{color}
       > git rev-list 762167f98c6aa8d47c801f8b6ac20bf30d786a4b # timeout=10
      

      Only the checkout operation has the set timeout of 30 minutes, all other operations keep the 10 minutes timeout. I'd awaited to see the new, longer timeout for all git operations!

      This way some git repositories can not be checked out by jenkins directly, since jenkins will run into a timeout, restarting the clone operation all over again, running into a timeout ...!

          [JENKINS-29164] Can't set timeout for git clone

          Mark Waite added a comment -

          I think you may have missed an option. There is an advanced checkout option and an advanced clone option. The timeout values may be adjusted independently through the two different options.

          Mark Waite added a comment - I think you may have missed an option. There is an advanced checkout option and an advanced clone option. The timeout values may be adjusted independently through the two different options.

          Yes, I missed this option. Now it works as expected.

          Thomas Schweikle added a comment - Yes, I missed this option. Now it works as expected.

          Mark Waite added a comment -

          That's great. I'm sorry that there are two settings like that. I think it is confusing to users. Unfortunately, I wanted to retain compatibility for existing users and that meant not risking a behavioral change by broadening the meaning of an existing value.

          The timeout on clone was the first option available and is still the most heavily used (because it commonly means network traffic rather than disc traffic). Some users reported that their checkout would fail due to timeout so the "timeout on checkout" option was added.

          Mark Waite added a comment - That's great. I'm sorry that there are two settings like that. I think it is confusing to users. Unfortunately, I wanted to retain compatibility for existing users and that meant not risking a behavioral change by broadening the meaning of an existing value. The timeout on clone was the first option available and is still the most heavily used (because it commonly means network traffic rather than disc traffic). Some users reported that their checkout would fail due to timeout so the "timeout on checkout" option was added.

            ndeloof Nicolas De Loof
            tps800 Thomas Schweikle
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: