I cherry picked the change to the 2.2.x, it should be available in 2.2.8
when it is released.

On Sat, Oct 25, 2014 at 11:41 AM, Mark Waite <[email protected]>
wrote:

> Sorry for the long delay in the reply.  The change to enable submodule
> timeout has only been applied to the master branch on the git-plugin.  The
> master branch is currently targeted for version 2.3.  A version of the
> plugin is available from the beta update center as 2.3-beta-3.
>
> The 2.2.x branch has not received that change, so no released version of
> the plugin includes that submodule timeout setting.
>
> Mark Waite
>
> On Tue, Sep 30, 2014 at 8:56 AM, Mark Waite <[email protected]>
> wrote:
>
>> Thanks.  You're correct.  If the timeout= value shows 10, then the
>> timeout is not being passed to the submodule fetch.
>>
>> Since there is code in the plugin to configure a timeout, there must be
>> something missing which is preventing that option from displaying in the
>> submodule config options of the plugin.
>>
>> You could submit a bug report, or you could investigate the problem and
>> submit a pull request to fix the problem (or both).
>>
>> Thanks,
>> Mark Waite
>>
>> On Tue, Sep 30, 2014 at 8:19 AM, abierbaum <[email protected]> wrote:
>>
>>> Mark:
>>>
>>> As best I can determine that timeout is not flowing through to
>>> submodules.  In the console output of my build job I see:
>>>
>>> > git init /jenkins_root/workspace/pylint_0_dev # timeout=10
>>> Fetching upstream changes from [email protected]:domain/project.git
>>>  > git --version # timeout=10
>>>  > git fetch --tags --progress [email protected]:domain/project.git 
>>> +refs/heads/*:refs/remotes/origin/*
>>> # timeout=30
>>>  > git config remote.origin.url [email protected]:domain/project.git #
>>> timeout=10
>>>  > git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* #
>>> timeout=10
>>>  > git config remote.origin.url [email protected]:domain/project.git #
>>> timeout=10
>>> Pruning obsolete local branches
>>> Fetching upstream changes from [email protected]:domain/project.git
>>>  > git fetch --tags --progress [email protected]:domain/project.git 
>>> +refs/heads/*:refs/remotes/origin/*
>>> --prune # timeout=30
>>> Checking out Revision 123456789abcd (origin/master)
>>>  > git config core.sparsecheckout # timeout=10
>>>  > git checkout -f 123456789abcd
>>>  > git rev-list 123456789abcd # timeout=10
>>>  > git remote # timeout=10
>>>  > git submodule init # timeout=10
>>>  > git submodule sync # timeout=10
>>>  > git config --get remote.origin.url # timeout=10
>>>  > git submodule update --init --recursive
>>> No emails were triggered.
>>>
>>> From the comments in there "timeout=" it looks like the timeout 30 only
>>> affects the git fetch commands on the main repo (and likely the initial git
>>> clone command).  The timeouts for the submodule commands seems to be 10
>>> minutes still.
>>>
>>> -Allen
>>>
>>>
>>> On Tuesday, September 30, 2014 9:05:15 AM UTC-5, Mark Waite wrote:
>>>>
>>>> I believe the clone timeout value specified in the "Additional
>>>> Behaviours" section "Advanced clone opitions" is also applied to submodules
>>>> fetch operations.
>>>>
>>>> Mark Waite
>>>>
>>>> On Tue, Sep 30, 2014 at 6:31 AM, abierbaum <[email protected]> wrote:
>>>>
>>>>> We have a Jenkins install that we have been using for years for
>>>>> running all of our build jobs.  Recently we ran into an issue with one of
>>>>> our git repositories where the initial submodules update would take longer
>>>>> than the 10 minute limit and would timeout.  I started looking for a
>>>>> solution and found that the Git Client Plugin [1] added support for a
>>>>> submodule timeout value in version 1.9.0 [2].  Looking at the code change
>>>>> [3], it looks like this should add a timeout field in the submodule 
>>>>> options
>>>>> section of the configuration.
>>>>>
>>>>> Based upon this, I updated Jenkins and all plugins.  (Jenkins 1.581,
>>>>> Git Plugin 2.2.6, Git Client Plugin 1.10.2).  After fixing a couple of
>>>>> issues where credentials didn't migrate, etc I have Jenkins up and running
>>>>> again as it was before the update.
>>>>>
>>>>> Unfortunately I can't find the submodule timeout option in the
>>>>> settings for Git on a job.  I tried removing the Git settings for a job 
>>>>> and
>>>>> even tried creating a new job from scratch, but I can't find any place in
>>>>> the UI to set the options for submodule.  This is what the screen looks
>>>>> like for me:
>>>>>
>>>>>
>>>>>
>>>>> <https://s3.amazonaws.com/uploads.hipchat.com/16008/63421/Ggs1PBs0c5bUj33/upload.png>
>>>>>
>>>>>
>>>>> Any ideas or something obvious I am missing?
>>>>>
>>>>> -Allen
>>>>>
>>>>>
>>>>> [1] https://wiki.jenkins-ci.org/display/JENKINS/Git+Client+Plugin
>>>>> [2] https://issues.jenkins-ci.org/browse/JENKINS-22400
>>>>> [3] https://github.com/jenkinsci/git-plugin/commit/
>>>>> 7dab96f8b5b1ea95e3a92123e6424376d7fa1036
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Jenkins Users" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks!
>>>> Mark Waite
>>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Thanks!
>> Mark Waite
>>
>
>
>
> --
> Thanks!
> Mark Waite
>



-- 
Thanks!
Mark Waite

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

Reply via email to