Re: Git Credentials on Workflow Plugin

[Ivo Bellin Salarin]

Which is this public repository where you're experiencing this problem?
May you give us the complete url?
Le Tue Feb 03 2015 at 10:37:45 AM, Arunkumar Perumal <
arunkumar.peru...@gmail.com> a écrit :

> 1. I'm trying to access public repository hence I've to use git-client
> 1.14.0
> 2. In the command line, it is running success after unset ask pass=true
>
> But it is not success in Jenkins :(
>
>
> On Tuesday, February 3, 2015 at 2:28:30 PM UTC+5:30, Ivo Bellin Salarin
> wrote:
>
>> Please,
>>
>
>> have a look at your GIT REPOSITORY SERVER logs.
>> These stacks are probably not related to the problem at all.
>>
>> To answer your other question, no, there's no way (in 1.14.0) to not pass
>> this option.
>>
>> Please consider that, even if you were allowed disable this option, you
>> could get a git process stuck waiting for credentials, and a Jenkins job
>> failing once the default timeout (10') has expired.
>>
>> You might also consider
>> 1) trying to reproduce the problem in a command line on the jenkins server
>> 2) downgrade to git-client 1.13 (unless you're accessing public git
>> repositories which could expose you to a security issue)
>>
>
>> Le Tue Feb 03 2015 at 6:15:28 AM, Arunkumar Perumal <
>> arunkuma...@gmail.com> a écrit :
>>
>>> Hello Mark,
>>>
>>> When I check the server logs it says the below
>>>
>>> Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
>>> SEVERE: Trying to unexport an object that's already unexported
>>> java.lang.IllegalStateException: Invalid object ID 102 iota=12324
>>> at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.
>>> java:348)
>>> at hudson.remoting.ExportTable.unexportByOid(ExportTable.java:371)
>>> at hudson.remoting.Channel.unexport(Channel.java:612)
>>> at hudson.remoting.UnexportCommand.execute(UnexportCommand.java:38)
>>> at hudson.remoting.Channel$2.handle(Channel.java:483)
>>> at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(
>>> SynchronousCommandTransport.java:60)
>>> Caused by: java.lang.Exception: Object appears to be deallocated at
>>> lease before Fri Jan 30 16:15:36 CET 2015
>>> at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.
>>> java:344)
>>> ... 5 more
>>>
>>> Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
>>> SEVERE: 2nd unexport attempt is here
>>> Command hudson.remoting.UnexportCommand@1fe8ba9 created at
>>> at hudson.remoting.Command.(Command.java:67)
>>> at hudson.remoting.Command.(Command.java:50)
>>> at hudson.remoting.UnexportCommand.(UnexportCommand.java:33)
>>> at hudson.remoting.RemoteInvocationHandler.finalize(
>>> RemoteInvocationHandler.java:221)
>>> at java.lang.System$2.invokeFinalize(Unknown Source)
>>> at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
>>> at java.lang.ref.Finalizer.access$100(Unknown Source)
>>> at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
>>>
>>> Not getting a clue. :(
>>>
>>>
>>> On Tuesday, February 3, 2015 at 10:28:33 AM UTC+5:30, Mark Waite wrote:
>>>
 I doubt very much that "-c core.askpass=true" would cause intermittent
 fetch failures.

 You might consider reading the log files of your git repository server,
 in case there is some hint in those logs which will tell you why it fails.

 Mark Waite

 On Mon, Feb 2, 2015 at 7:55 PM, Arunkumar Perumal <
 arunkuma...@gmail.com> wrote:

>>> Ivo,
>
> Sorry, pls find below the details. I have job which will fetch the
> data from the remote repository & I've setup the proxy details.
>
> The same job is getting success for a couple of times but after that
> it started failing. I'm using git client plugin 1.14.0, git plugin 2.3.2.
> Couldn't understand how this is getting success some time & all other time
> failing :(.
>
> So I thought of removing the -c core.askpass=true option may help.
>
> success case:
>
> using .gitcredentials to set credentials
>  > /usr/local/git_1.8.4.4/bin/git config --local credential.helper
> store --file=/tmp/git94958994918016.credentials # timeout=10
> Setting http proxy: server:8080
>  > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags
> --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
>  > /usr/local/git_1.8.4.4/bin/git config --local --remove-section
> credential # timeout=10
>  > /usr/local/git_1.8.4.4/bin/git rev-parse
> refs/remotes/origin/master^{commit} # timeout=10
>  > /usr/local/git_1.8.4.4/bin/git rev-parse refs/remotes/origin/origin/
> master^{commit} # timeout=10
> Checking out Revision 8e4b0169a13bbc56d3dad066ee44eae184ec0162
> (refs/remotes/origin/master)
>  > /usr/local/git_1.8.4.4/bin/git config core.sparsecheckout #
> timeout=10
>  > /usr/local/git_1.8.4.4/bin/git checkout -f
> 8e4b0169a13bbc56d3dad066ee44eae184ec0162
>  > /usr/local/git_1.8.4.4/

Re: Git Credentials on Workflow Plugin

[Arunkumar Perumal]

1. I'm trying to access public repository hence I've to use git-client 
1.14.0
2. In the command line, it is running success after unset ask pass=true

But it is not success in Jenkins :(

On Tuesday, February 3, 2015 at 2:28:30 PM UTC+5:30, Ivo Bellin Salarin 
wrote:
>
> Please,
>
> have a look at your GIT REPOSITORY SERVER logs.
> These stacks are probably not related to the problem at all.
>
> To answer your other question, no, there's no way (in 1.14.0) to not pass 
> this option.
>
> Please consider that, even if you were allowed disable this option, you 
> could get a git process stuck waiting for credentials, and a Jenkins job 
> failing once the default timeout (10') has expired.
>
> You might also consider
> 1) trying to reproduce the problem in a command line on the jenkins server
> 2) downgrade to git-client 1.13 (unless you're accessing public git 
> repositories which could expose you to a security issue)
>
> Le Tue Feb 03 2015 at 6:15:28 AM, Arunkumar Perumal  > a écrit :
>
>> Hello Mark,
>>
>> When I check the server logs it says the below
>>
>> Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
>> SEVERE: Trying to unexport an object that's already unexported
>> java.lang.IllegalStateException: Invalid object ID 102 iota=12324
>> at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:348)
>> at hudson.remoting.ExportTable.unexportByOid(ExportTable.java:371)
>> at hudson.remoting.Channel.unexport(Channel.java:612)
>> at hudson.remoting.UnexportCommand.execute(UnexportCommand.java:38)
>> at hudson.remoting.Channel$2.handle(Channel.java:483)
>> at 
>> hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60)
>> Caused by: java.lang.Exception: Object appears to be deallocated at lease 
>> before Fri Jan 30 16:15:36 CET 2015
>> at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:344)
>> ... 5 more
>>
>> Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
>> SEVERE: 2nd unexport attempt is here
>> Command hudson.remoting.UnexportCommand@1fe8ba9 created at
>> at hudson.remoting.Command.(Command.java:67)
>> at hudson.remoting.Command.(Command.java:50)
>> at hudson.remoting.UnexportCommand.(UnexportCommand.java:33)
>> at 
>> hudson.remoting.RemoteInvocationHandler.finalize(RemoteInvocationHandler.java:221)
>> at java.lang.System$2.invokeFinalize(Unknown Source)
>> at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
>> at java.lang.ref.Finalizer.access$100(Unknown Source)
>> at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
>>
>> Not getting a clue. :(
>>
>>
>> On Tuesday, February 3, 2015 at 10:28:33 AM UTC+5:30, Mark Waite wrote:
>>
>>> I doubt very much that "-c core.askpass=true" would cause intermittent 
>>> fetch failures.
>>>
>>> You might consider reading the log files of your git repository server, 
>>> in case there is some hint in those logs which will tell you why it fails.
>>>
>>> Mark Waite
>>>
>>> On Mon, Feb 2, 2015 at 7:55 PM, Arunkumar Perumal >> > wrote:
>>>
>> Ivo,

 Sorry, pls find below the details. I have job which will fetch the data 
 from the remote repository & I've setup the proxy details.

 The same job is getting success for a couple of times but after that it 
 started failing. I'm using git client plugin 1.14.0, git plugin 2.3.2. 
 Couldn't understand how this is getting success some time & all other time 
 failing :(. 

 So I thought of removing the -c core.askpass=true option may help.

 success case:

 using .gitcredentials to set credentials
  > /usr/local/git_1.8.4.4/bin/git config --local credential.helper 
 store --file=/tmp/git94958994918016.credentials # timeout=10
 Setting http proxy: server:8080
  > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags 
 --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
  > /usr/local/git_1.8.4.4/bin/git config --local --remove-section 
 credential # timeout=10
  > /usr/local/git_1.8.4.4/bin/git rev-parse 
 refs/remotes/origin/master^{commit} 
 # timeout=10
  > /usr/local/git_1.8.4.4/bin/git rev-parse 
 refs/remotes/origin/origin/master^{commit} 
 # timeout=10
 Checking out Revision 8e4b0169a13bbc56d3dad066ee44eae184ec0162 
 (refs/remotes/origin/master)
  > /usr/local/git_1.8.4.4/bin/git config core.sparsecheckout # 
 timeout=10
  > /usr/local/git_1.8.4.4/bin/git checkout -f 
 8e4b0169a13bbc56d3dad066ee44eae184ec0162
  > /usr/local/git_1.8.4.4/bin/git rev-list 
 901c14ef7620cd409cb1712a30803742a8d49357 # timeout=10

 failure case:

 using .gitcredentials to set credentials
  > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store 
 --file=/tmp/git7741299244057538477.credentials # timeout=10

 Setting http proxy: server:8080
  > /

Re: Git Credentials on Workflow Plugin

[Ivo Bellin Salarin]

Please,

have a look at your GIT REPOSITORY SERVER logs.
These stacks are probably not related to the problem at all.

To answer your other question, no, there's no way (in 1.14.0) to not pass
this option.

Please consider that, even if you were allowed disable this option, you
could get a git process stuck waiting for credentials, and a Jenkins job
failing once the default timeout (10') has expired.

You might also consider
1) trying to reproduce the problem in a command line on the jenkins server
2) downgrade to git-client 1.13 (unless you're accessing public git
repositories which could expose you to a security issue)

Le Tue Feb 03 2015 at 6:15:28 AM, Arunkumar Perumal <
arunkumar.peru...@gmail.com> a écrit :

> Hello Mark,
>
> When I check the server logs it says the below
>
> Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
> SEVERE: Trying to unexport an object that's already unexported
> java.lang.IllegalStateException: Invalid object ID 102 iota=12324
> at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:348)
> at hudson.remoting.ExportTable.unexportByOid(ExportTable.java:371)
> at hudson.remoting.Channel.unexport(Channel.java:612)
> at hudson.remoting.UnexportCommand.execute(UnexportCommand.java:38)
> at hudson.remoting.Channel$2.handle(Channel.java:483)
> at
> hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60)
> Caused by: java.lang.Exception: Object appears to be deallocated at lease
> before Fri Jan 30 16:15:36 CET 2015
> at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:344)
> ... 5 more
>
> Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
> SEVERE: 2nd unexport attempt is here
> Command hudson.remoting.UnexportCommand@1fe8ba9 created at
> at hudson.remoting.Command.(Command.java:67)
> at hudson.remoting.Command.(Command.java:50)
> at hudson.remoting.UnexportCommand.(UnexportCommand.java:33)
> at
> hudson.remoting.RemoteInvocationHandler.finalize(RemoteInvocationHandler.java:221)
> at java.lang.System$2.invokeFinalize(Unknown Source)
> at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
> at java.lang.ref.Finalizer.access$100(Unknown Source)
> at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
>
> Not getting a clue. :(
>
>
> On Tuesday, February 3, 2015 at 10:28:33 AM UTC+5:30, Mark Waite wrote:
>
>> I doubt very much that "-c core.askpass=true" would cause intermittent
>> fetch failures.
>>
>> You might consider reading the log files of your git repository server,
>> in case there is some hint in those logs which will tell you why it fails.
>>
>> Mark Waite
>>
>> On Mon, Feb 2, 2015 at 7:55 PM, Arunkumar Perumal 
>> wrote:
>>
> Ivo,
>>>
>>> Sorry, pls find below the details. I have job which will fetch the data
>>> from the remote repository & I've setup the proxy details.
>>>
>>> The same job is getting success for a couple of times but after that it
>>> started failing. I'm using git client plugin 1.14.0, git plugin 2.3.2.
>>> Couldn't understand how this is getting success some time & all other time
>>> failing :(.
>>>
>>> So I thought of removing the -c core.askpass=true option may help.
>>>
>>> success case:
>>>
>>> using .gitcredentials to set credentials
>>>  > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store
>>> --file=/tmp/git94958994918016.credentials # timeout=10
>>> Setting http proxy: server:8080
>>>  > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags
>>> --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
>>>  > /usr/local/git_1.8.4.4/bin/git config --local --remove-section
>>> credential # timeout=10
>>>  > /usr/local/git_1.8.4.4/bin/git rev-parse 
>>> refs/remotes/origin/master^{commit}
>>> # timeout=10
>>>  > /usr/local/git_1.8.4.4/bin/git rev-parse 
>>> refs/remotes/origin/origin/master^{commit}
>>> # timeout=10
>>> Checking out Revision 8e4b0169a13bbc56d3dad066ee44eae184ec0162
>>> (refs/remotes/origin/master)
>>>  > /usr/local/git_1.8.4.4/bin/git config core.sparsecheckout # timeout=10
>>>  > /usr/local/git_1.8.4.4/bin/git checkout -f
>>> 8e4b0169a13bbc56d3dad066ee44eae184ec0162
>>>  > /usr/local/git_1.8.4.4/bin/git rev-list 
>>> 901c14ef7620cd409cb1712a30803742a8d49357
>>> # timeout=10
>>>
>>> failure case:
>>>
>>> using .gitcredentials to set credentials
>>>  > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store 
>>> --file=/tmp/git7741299244057538477.credentials # timeout=10
>>>
>>> Setting http proxy: server:8080
>>>  > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags
>>> --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
>>>  > /usr/local/git_1.8.4.4/bin/git config --local --remove-section
>>> credential # timeout=10
>>> ERROR: Error fetching remote repo 'origin'
>>> ERROR: Error fetching remote repo 'origin'
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tuesday, February 3, 201

Re: Git Credentials on Workflow Plugin

[Arunkumar Perumal]

Mark,

Is there any way I could avoid "-c core.askpass=true" using Git Client 
Plugin 1.14.0?

On Tuesday, February 3, 2015 at 10:45:24 AM UTC+5:30, Arunkumar Perumal 
wrote:
>
> Hello Mark,
>
> When I check the server logs it says the below
>
> Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
> SEVERE: Trying to unexport an object that's already unexported
> java.lang.IllegalStateException: Invalid object ID 102 iota=12324
> at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:348)
> at hudson.remoting.ExportTable.unexportByOid(ExportTable.java:371)
> at hudson.remoting.Channel.unexport(Channel.java:612)
> at hudson.remoting.UnexportCommand.execute(UnexportCommand.java:38)
> at hudson.remoting.Channel$2.handle(Channel.java:483)
> at 
> hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60)
> Caused by: java.lang.Exception: Object appears to be deallocated at lease 
> before Fri Jan 30 16:15:36 CET 2015
> at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:344)
> ... 5 more
>
> Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
> SEVERE: 2nd unexport attempt is here
> Command hudson.remoting.UnexportCommand@1fe8ba9 created at
> at hudson.remoting.Command.(Command.java:67)
> at hudson.remoting.Command.(Command.java:50)
> at hudson.remoting.UnexportCommand.(UnexportCommand.java:33)
> at 
> hudson.remoting.RemoteInvocationHandler.finalize(RemoteInvocationHandler.java:221)
> at java.lang.System$2.invokeFinalize(Unknown Source)
> at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
> at java.lang.ref.Finalizer.access$100(Unknown Source)
> at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
>
> Not getting a clue. :(
>
> On Tuesday, February 3, 2015 at 10:28:33 AM UTC+5:30, Mark Waite wrote:
>>
>> I doubt very much that "-c core.askpass=true" would cause intermittent 
>> fetch failures.
>>
>> You might consider reading the log files of your git repository server, 
>> in case there is some hint in those logs which will tell you why it fails.
>>
>> Mark Waite
>>
>>
>> On Mon, Feb 2, 2015 at 7:55 PM, Arunkumar Perumal  
>> wrote:
>>
>>> Ivo,
>>>
>>> Sorry, pls find below the details. I have job which will fetch the data 
>>> from the remote repository & I've setup the proxy details.
>>>
>>> The same job is getting success for a couple of times but after that it 
>>> started failing. I'm using git client plugin 1.14.0, git plugin 2.3.2. 
>>> Couldn't understand how this is getting success some time & all other time 
>>> failing :(. 
>>>
>>> So I thought of removing the -c core.askpass=true option may help.
>>>
>>> success case:
>>>
>>> using .gitcredentials to set credentials
>>>  > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store 
>>> --file=/tmp/git94958994918016.credentials # timeout=10
>>> Setting http proxy: server:8080
>>>  > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags 
>>> --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
>>>  > /usr/local/git_1.8.4.4/bin/git config --local --remove-section 
>>> credential # timeout=10
>>>  > /usr/local/git_1.8.4.4/bin/git rev-parse 
>>> refs/remotes/origin/master^{commit} # timeout=10
>>>  > /usr/local/git_1.8.4.4/bin/git rev-parse 
>>> refs/remotes/origin/origin/master^{commit} # timeout=10
>>> Checking out Revision 8e4b0169a13bbc56d3dad066ee44eae184ec0162 
>>> (refs/remotes/origin/master)
>>>  > /usr/local/git_1.8.4.4/bin/git config core.sparsecheckout # timeout=10
>>>  > /usr/local/git_1.8.4.4/bin/git checkout -f 
>>> 8e4b0169a13bbc56d3dad066ee44eae184ec0162
>>>  > /usr/local/git_1.8.4.4/bin/git rev-list 
>>> 901c14ef7620cd409cb1712a30803742a8d49357 # timeout=10
>>>
>>> failure case:
>>>
>>> using .gitcredentials to set credentials
>>>  > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store 
>>> --file=/tmp/git7741299244057538477.credentials # timeout=10
>>>
>>> Setting http proxy: server:8080
>>>  > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags 
>>> --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
>>>  > /usr/local/git_1.8.4.4/bin/git config --local --remove-section 
>>> credential # timeout=10
>>> ERROR: Error fetching remote repo 'origin'
>>> ERROR: Error fetching remote repo 'origin'
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tuesday, February 3, 2015 at 12:20:52 AM UTC+5:30, Ivo Bellin Salarin 
>>> wrote:

 I will try to justify a little more the existence of the -c 
 core.askpass=true option.
 This is essentially a  "a la volée" modification of the .gitconfig 
 content. 

 This option says to git to use /bin/true (which always returns 1) as 
 identity manager in the case where the remote server asks an explicit 
 authentication. Or, in the case the provided identification isn't 
 sufficient for the remote server needs.

 (Even 

Re: Git Credentials on Workflow Plugin

[Arunkumar Perumal]

Hello Mark,

When I check the server logs it says the below

Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
SEVERE: Trying to unexport an object that's already unexported
java.lang.IllegalStateException: Invalid object ID 102 iota=12324
at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:348)
at hudson.remoting.ExportTable.unexportByOid(ExportTable.java:371)
at hudson.remoting.Channel.unexport(Channel.java:612)
at hudson.remoting.UnexportCommand.execute(UnexportCommand.java:38)
at hudson.remoting.Channel$2.handle(Channel.java:483)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60)
Caused by: java.lang.Exception: Object appears to be deallocated at lease 
before Fri Jan 30 16:15:36 CET 2015
at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:344)
... 5 more

Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
SEVERE: 2nd unexport attempt is here
Command hudson.remoting.UnexportCommand@1fe8ba9 created at
at hudson.remoting.Command.(Command.java:67)
at hudson.remoting.Command.(Command.java:50)
at hudson.remoting.UnexportCommand.(UnexportCommand.java:33)
at 
hudson.remoting.RemoteInvocationHandler.finalize(RemoteInvocationHandler.java:221)
at java.lang.System$2.invokeFinalize(Unknown Source)
at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
at java.lang.ref.Finalizer.access$100(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)

Not getting a clue. :(

On Tuesday, February 3, 2015 at 10:28:33 AM UTC+5:30, Mark Waite wrote:
>
> I doubt very much that "-c core.askpass=true" would cause intermittent 
> fetch failures.
>
> You might consider reading the log files of your git repository server, in 
> case there is some hint in those logs which will tell you why it fails.
>
> Mark Waite
>
>
> On Mon, Feb 2, 2015 at 7:55 PM, Arunkumar Perumal  > wrote:
>
>> Ivo,
>>
>> Sorry, pls find below the details. I have job which will fetch the data 
>> from the remote repository & I've setup the proxy details.
>>
>> The same job is getting success for a couple of times but after that it 
>> started failing. I'm using git client plugin 1.14.0, git plugin 2.3.2. 
>> Couldn't understand how this is getting success some time & all other time 
>> failing :(. 
>>
>> So I thought of removing the -c core.askpass=true option may help.
>>
>> success case:
>>
>> using .gitcredentials to set credentials
>>  > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store 
>> --file=/tmp/git94958994918016.credentials # timeout=10
>> Setting http proxy: server:8080
>>  > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags 
>> --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
>>  > /usr/local/git_1.8.4.4/bin/git config --local --remove-section 
>> credential # timeout=10
>>  > /usr/local/git_1.8.4.4/bin/git rev-parse 
>> refs/remotes/origin/master^{commit} # timeout=10
>>  > /usr/local/git_1.8.4.4/bin/git rev-parse 
>> refs/remotes/origin/origin/master^{commit} # timeout=10
>> Checking out Revision 8e4b0169a13bbc56d3dad066ee44eae184ec0162 
>> (refs/remotes/origin/master)
>>  > /usr/local/git_1.8.4.4/bin/git config core.sparsecheckout # timeout=10
>>  > /usr/local/git_1.8.4.4/bin/git checkout -f 
>> 8e4b0169a13bbc56d3dad066ee44eae184ec0162
>>  > /usr/local/git_1.8.4.4/bin/git rev-list 
>> 901c14ef7620cd409cb1712a30803742a8d49357 # timeout=10
>>
>> failure case:
>>
>> using .gitcredentials to set credentials
>>  > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store 
>> --file=/tmp/git7741299244057538477.credentials # timeout=10
>>
>> Setting http proxy: server:8080
>>  > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags 
>> --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
>>  > /usr/local/git_1.8.4.4/bin/git config --local --remove-section 
>> credential # timeout=10
>> ERROR: Error fetching remote repo 'origin'
>> ERROR: Error fetching remote repo 'origin'
>>
>>
>>
>>
>>
>>
>>
>> On Tuesday, February 3, 2015 at 12:20:52 AM UTC+5:30, Ivo Bellin Salarin 
>> wrote:
>>>
>>> I will try to justify a little more the existence of the -c 
>>> core.askpass=true option.
>>> This is essentially a  "a la volée" modification of the .gitconfig 
>>> content. 
>>>
>>> This option says to git to use /bin/true (which always returns 1) as 
>>> identity manager in the case where the remote server asks an explicit 
>>> authentication. Or, in the case the provided identification isn't 
>>> sufficient for the remote server needs.
>>>
>>> (Even more detailed and precise documentation can be found on 
>>> http://git-scm.com/docs/git-config)
>>>
>>> In versions before the 1.14, the git client plugin was using an explicit 
>>> http connection to test the provided credentials.
>>>
>>> Such approach was limited, when compared to the libraries used by git 
>>> itself. 

Re: Git Credentials on Workflow Plugin

[Mark Waite]

I doubt very much that "-c core.askpass=true" would cause intermittent
fetch failures.

You might consider reading the log files of your git repository server, in
case there is some hint in those logs which will tell you why it fails.

Mark Waite


On Mon, Feb 2, 2015 at 7:55 PM, Arunkumar Perumal <
arunkumar.peru...@gmail.com> wrote:

> Ivo,
>
> Sorry, pls find below the details. I have job which will fetch the data
> from the remote repository & I've setup the proxy details.
>
> The same job is getting success for a couple of times but after that it
> started failing. I'm using git client plugin 1.14.0, git plugin 2.3.2.
> Couldn't understand how this is getting success some time & all other time
> failing :(.
>
> So I thought of removing the -c core.askpass=true option may help.
>
> success case:
>
> using .gitcredentials to set credentials
>  > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store
> --file=/tmp/git94958994918016.credentials # timeout=10
> Setting http proxy: server:8080
>  > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags
> --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
>  > /usr/local/git_1.8.4.4/bin/git config --local --remove-section
> credential # timeout=10
>  > /usr/local/git_1.8.4.4/bin/git rev-parse
> refs/remotes/origin/master^{commit} # timeout=10
>  > /usr/local/git_1.8.4.4/bin/git rev-parse
> refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision 8e4b0169a13bbc56d3dad066ee44eae184ec0162
> (refs/remotes/origin/master)
>  > /usr/local/git_1.8.4.4/bin/git config core.sparsecheckout # timeout=10
>  > /usr/local/git_1.8.4.4/bin/git checkout -f
> 8e4b0169a13bbc56d3dad066ee44eae184ec0162
>  > /usr/local/git_1.8.4.4/bin/git rev-list
> 901c14ef7620cd409cb1712a30803742a8d49357 # timeout=10
>
> failure case:
>
> using .gitcredentials to set credentials
>  > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store 
> --file=/tmp/git7741299244057538477.credentials # timeout=10
>
> Setting http proxy: server:8080
>  > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags
> --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
>  > /usr/local/git_1.8.4.4/bin/git config --local --remove-section
> credential # timeout=10
> ERROR: Error fetching remote repo 'origin'
> ERROR: Error fetching remote repo 'origin'
>
>
>
>
>
>
>
> On Tuesday, February 3, 2015 at 12:20:52 AM UTC+5:30, Ivo Bellin Salarin
> wrote:
>>
>> I will try to justify a little more the existence of the -c
>> core.askpass=true option.
>> This is essentially a  "a la volée" modification of the .gitconfig
>> content.
>>
>> This option says to git to use /bin/true (which always returns 1) as
>> identity manager in the case where the remote server asks an explicit
>> authentication. Or, in the case the provided identification isn't
>> sufficient for the remote server needs.
>>
>> (Even more detailed and precise documentation can be found on
>> http://git-scm.com/docs/git-config)
>>
>> In versions before the 1.14, the git client plugin was using an explicit
>> http connection to test the provided credentials.
>>
>> Such approach was limited, when compared to the libraries used by git
>> itself. These libraries are able to use several authentication schemas,
>> which weren't supported by the git-client plugin.
>>
>> I hope that these details satisfy your needs. I hope to get more details
>> about the misbehaviors that this option is causing to you.
>>
>> Thanks in advance,
>> Ivo
>>
>> Il giorno lun 2 feb 2015 19:13 Ivo Bellin Salarin 
>> ha scritto:
>>
>>> Dear user of the git plugin,
>>>
>>> Is this option causing some misbehavior in your environment?
>>> Could you please describe it?
>>>
>>> Or, yours is rather a conservative attitude towards changes which could
>>> deteriorate your build environment?
>>>
>>> Il giorno lun 2 feb 2015 17:57 Arunkumar Perumal 
>>> ha scritto:
>>>
>>> Hello Mark,

 When I use Git Client Plugin 1.13.0, I'm not getting -c
 core.askpass=true.

 But when I use, 1.14.0, its using that option but you have released the
 change in 1.14.1. Could you please let me know how I can skip this
 particular step in Git Client Plugin 1.14.0

 1.14.1 (Dec 27, 2014)

- Only use "-c core.askpass=true" if command line git is newer than
1.7.9 (don't break really old git versions unnecessarily)

 1.14.0 (Dec 25, 2014)

- Update from JGit 3.5.3 to JGit 3.6.0
-   Use command line credentials check when using command line git 
 (issue
#22675 , issue
#22909 , issue
#23050 , issue
#20533 )



 On Wednesday, January 28, 2015 at 10:01:24 AM UTC+5:30, Mark Waite
 wrote

Re: Git Credentials on Workflow Plugin

[Arunkumar Perumal]

Ivo,

Sorry, pls find below the details. I have job which will fetch the data 
from the remote repository & I've setup the proxy details.

The same job is getting success for a couple of times but after that it 
started failing. I'm using git client plugin 1.14.0, git plugin 2.3.2. 
Couldn't understand how this is getting success some time & all other time 
failing :(. 

So I thought of removing the -c core.askpass=true option may help.

success case:

using .gitcredentials to set credentials
 > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store 
--file=/tmp/git94958994918016.credentials # timeout=10
Setting http proxy: server:8080
 > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags 
--progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
 > /usr/local/git_1.8.4.4/bin/git config --local --remove-section 
credential # timeout=10
 > /usr/local/git_1.8.4.4/bin/git rev-parse 
refs/remotes/origin/master^{commit} # timeout=10
 > /usr/local/git_1.8.4.4/bin/git rev-parse 
refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 8e4b0169a13bbc56d3dad066ee44eae184ec0162 
(refs/remotes/origin/master)
 > /usr/local/git_1.8.4.4/bin/git config core.sparsecheckout # timeout=10
 > /usr/local/git_1.8.4.4/bin/git checkout -f 
8e4b0169a13bbc56d3dad066ee44eae184ec0162
 > /usr/local/git_1.8.4.4/bin/git rev-list 
901c14ef7620cd409cb1712a30803742a8d49357 # timeout=10

failure case:

using .gitcredentials to set credentials
 > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store 
 > --file=/tmp/git7741299244057538477.credentials # timeout=10

Setting http proxy: server:8080
 > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags 
--progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
 > /usr/local/git_1.8.4.4/bin/git config --local --remove-section 
credential # timeout=10
ERROR: Error fetching remote repo 'origin'
ERROR: Error fetching remote repo 'origin'







On Tuesday, February 3, 2015 at 12:20:52 AM UTC+5:30, Ivo Bellin Salarin 
wrote:
>
> I will try to justify a little more the existence of the -c 
> core.askpass=true option.
> This is essentially a  "a la volée" modification of the .gitconfig 
> content. 
>
> This option says to git to use /bin/true (which always returns 1) as 
> identity manager in the case where the remote server asks an explicit 
> authentication. Or, in the case the provided identification isn't 
> sufficient for the remote server needs.
>
> (Even more detailed and precise documentation can be found on 
> http://git-scm.com/docs/git-config)
>
> In versions before the 1.14, the git client plugin was using an explicit 
> http connection to test the provided credentials.
>
> Such approach was limited, when compared to the libraries used by git 
> itself. These libraries are able to use several authentication schemas, 
> which weren't supported by the git-client plugin.
>
> I hope that these details satisfy your needs. I hope to get more details 
> about the misbehaviors that this option is causing to you.
>
> Thanks in advance,
> Ivo
>
> Il giorno lun 2 feb 2015 19:13 Ivo Bellin Salarin  > ha scritto:
>
>> Dear user of the git plugin, 
>>
>> Is this option causing some misbehavior in your environment?
>> Could you please describe it?
>>
>> Or, yours is rather a conservative attitude towards changes which could 
>> deteriorate your build environment?
>>
>> Il giorno lun 2 feb 2015 17:57 Arunkumar Perumal > > ha scritto:
>>
>> Hello Mark,
>>>
>>> When I use Git Client Plugin 1.13.0, I'm not getting -c 
>>> core.askpass=true.
>>>
>>> But when I use, 1.14.0, its using that option but you have released the 
>>> change in 1.14.1. Could you please let me know how I can skip this 
>>> particular step in Git Client Plugin 1.14.0
>>>
>>> 1.14.1 (Dec 27, 2014) 
>>>
>>>- Only use "-c core.askpass=true" if command line git is newer than 
>>>1.7.9 (don't break really old git versions unnecessarily)
>>>
>>> 1.14.0 (Dec 25, 2014) 
>>>
>>>- Update from JGit 3.5.3 to JGit 3.6.0
>>>-   Use command line credentials check when using command line git 
>>> (issue 
>>>#22675 , issue 
>>>#22909 , issue 
>>>#23050 , issue 
>>>#20533 )
>>>
>>>
>>>
>>> On Wednesday, January 28, 2015 at 10:01:24 AM UTC+5:30, Mark Waite wrote:
>>>
 The "-c core.askpass=true" is used to prevent the git command line call 
 from prompting for a password from stdin.  It was added in a recent 
 git-client-plugin and was a key change to enable resolution of several 
 other bugs.  I doubt very much that argument is causing an authentication 
 problem.

>>> On Tue, Jan 27, 2015 at 9:15 AM, Rob Mandeville <
 rmand...@dekaresearch.com> wrote:

>  I am using:
>
>

Re: Git Credentials on Workflow Plugin

[Ivo Bellin Salarin]

I will try to justify a little more the existence of the -c
core.askpass=true option.
This is essentially a  "a la volée" modification of the .gitconfig content.

This option says to git to use /bin/true (which always returns 1) as
identity manager in the case where the remote server asks an explicit
authentication. Or, in the case the provided identification isn't
sufficient for the remote server needs.

(Even more detailed and precise documentation can be found on
http://git-scm.com/docs/git-config)

In versions before the 1.14, the git client plugin was using an explicit
http connection to test the provided credentials.

Such approach was limited, when compared to the libraries used by git
itself. These libraries are able to use several authentication schemas,
which weren't supported by the git-client plugin.

I hope that these details satisfy your needs. I hope to get more details
about the misbehaviors that this option is causing to you.

Thanks in advance,
Ivo

Il giorno lun 2 feb 2015 19:13 Ivo Bellin Salarin <
ivo.bellinsala...@gmail.com> ha scritto:

> Dear user of the git plugin,
>
> Is this option causing some misbehavior in your environment?
> Could you please describe it?
>
> Or, yours is rather a conservative attitude towards changes which could
> deteriorate your build environment?
>
> Il giorno lun 2 feb 2015 17:57 Arunkumar Perumal <
> arunkumar.peru...@gmail.com> ha scritto:
>
> Hello Mark,
>>
>> When I use Git Client Plugin 1.13.0, I'm not getting -c core.askpass=true.
>>
>> But when I use, 1.14.0, its using that option but you have released the
>> change in 1.14.1. Could you please let me know how I can skip this
>> particular step in Git Client Plugin 1.14.0
>>
>> 1.14.1 (Dec 27, 2014)
>>
>>- Only use "-c core.askpass=true" if command line git is newer than
>>1.7.9 (don't break really old git versions unnecessarily)
>>
>> 1.14.0 (Dec 25, 2014)
>>
>>- Update from JGit 3.5.3 to JGit 3.6.0
>>-   Use command line credentials check when using command line git (issue
>>#22675 , issue
>>#22909 , issue
>>#23050 , issue
>>#20533 )
>>
>>
>>
>> On Wednesday, January 28, 2015 at 10:01:24 AM UTC+5:30, Mark Waite wrote:
>>
>>> The "-c core.askpass=true" is used to prevent the git command line call
>>> from prompting for a password from stdin.  It was added in a recent
>>> git-client-plugin and was a key change to enable resolution of several
>>> other bugs.  I doubt very much that argument is causing an authentication
>>> problem.
>>>
>> On Tue, Jan 27, 2015 at 9:15 AM, Rob Mandeville <
>>> rmand...@dekaresearch.com> wrote:
>>>
  I am using:

 · Jenkins 1.580.2

 · GIT client plugin 1.15.0

 · GIT plugin 2.3.4

 · Workflow plugins 1.1

 · Credentials plugin 1.22



 We use GitLab for source control and do not allow anonymous access of
 any kind.  We use the Credentials plugin, have put in credentials allowing
 us access to Git, and on our normal projects, we simply give Git these
 pre-loaded credentials.  Now, I’m trying to create a Workflow job.



 I can’t find any doc which says how to feed credentials to Git, so I
 went to the credentials plugin and pulled the plugin ID from the URL.  I
 then wrote the following Groovy CPS DSL script (without the redactions,
 obviously):





 steps.stage('Setup')

 node('mock_builder') {

String templateUrl = 'git@URL_REDACTED'

steps.git(url: templateUrl, credentialsId: 'ID_REDACTED')

sh 'echo hello world'

 }



 The job gets stuck in the SCM step and exits with the following output:



 Running: Setup

 Entering stage Setup

 Proceeding

 Running: Allocate node : Start

 Running on mock_builder in 
 C:\Windows\TEMP\hudson1572436821107746068tmp\workspace\Try a Workflow

 Running: Allocate node : Body : Start

 Running: Git

  > git.exe rev-parse --is-inside-work-tree # timeout=10

 Fetching changes from the remote Git repository

  > git.exe config remote.origin.url git@URL_REDACTED # timeout=10

 Fetching upstream changes from git@URL_REDACTED

  > git.exe --version # timeout=10

  > git.exe -c core.askpass=true fetch --tags --progress git@URL_REDACTED 
 +refs/heads/*:refs/remotes/origin/*

 ERROR: Timeout after 10 minutes

 ERROR : Error 
 fetching remote repo 'origin'

 Running : Allocate 
 node : Body : End

 Running: Allocate node 

Re: Git Credentials on Workflow Plugin

[Ivo Bellin Salarin]

Dear user of the git plugin,

Is this option causing some misbehavior in your environment?
Could you please describe it?

Or, yours is rather a conservative attitude towards changes which could
deteriorate your build environment?

Il giorno lun 2 feb 2015 17:57 Arunkumar Perumal <
arunkumar.peru...@gmail.com> ha scritto:

> Hello Mark,
>
> When I use Git Client Plugin 1.13.0, I'm not getting -c core.askpass=true.
>
> But when I use, 1.14.0, its using that option but you have released the
> change in 1.14.1. Could you please let me know how I can skip this
> particular step in Git Client Plugin 1.14.0
>
> 1.14.1 (Dec 27, 2014)
>
>- Only use "-c core.askpass=true" if command line git is newer than
>1.7.9 (don't break really old git versions unnecessarily)
>
> 1.14.0 (Dec 25, 2014)
>
>- Update from JGit 3.5.3 to JGit 3.6.0
>-   Use command line credentials check when using command line git (issue
>#22675 , issue
>#22909 , issue
>#23050 , issue
>#20533 )
>
>
>
> On Wednesday, January 28, 2015 at 10:01:24 AM UTC+5:30, Mark Waite wrote:
>
>> The "-c core.askpass=true" is used to prevent the git command line call
>> from prompting for a password from stdin.  It was added in a recent
>> git-client-plugin and was a key change to enable resolution of several
>> other bugs.  I doubt very much that argument is causing an authentication
>> problem.
>>
> On Tue, Jan 27, 2015 at 9:15 AM, Rob Mandeville > > wrote:
>>
>>>  I am using:
>>>
>>> · Jenkins 1.580.2
>>>
>>> · GIT client plugin 1.15.0
>>>
>>> · GIT plugin 2.3.4
>>>
>>> · Workflow plugins 1.1
>>>
>>> · Credentials plugin 1.22
>>>
>>>
>>>
>>> We use GitLab for source control and do not allow anonymous access of
>>> any kind.  We use the Credentials plugin, have put in credentials allowing
>>> us access to Git, and on our normal projects, we simply give Git these
>>> pre-loaded credentials.  Now, I’m trying to create a Workflow job.
>>>
>>>
>>>
>>> I can’t find any doc which says how to feed credentials to Git, so I
>>> went to the credentials plugin and pulled the plugin ID from the URL.  I
>>> then wrote the following Groovy CPS DSL script (without the redactions,
>>> obviously):
>>>
>>>
>>>
>>>
>>>
>>> steps.stage('Setup')
>>>
>>> node('mock_builder') {
>>>
>>>String templateUrl = 'git@URL_REDACTED'
>>>
>>>steps.git(url: templateUrl, credentialsId: 'ID_REDACTED')
>>>
>>>sh 'echo hello world'
>>>
>>> }
>>>
>>>
>>>
>>> The job gets stuck in the SCM step and exits with the following output:
>>>
>>>
>>>
>>> Running: Setup
>>>
>>> Entering stage Setup
>>>
>>> Proceeding
>>>
>>> Running: Allocate node : Start
>>>
>>> Running on mock_builder in 
>>> C:\Windows\TEMP\hudson1572436821107746068tmp\workspace\Try a Workflow
>>>
>>> Running: Allocate node : Body : Start
>>>
>>> Running: Git
>>>
>>>  > git.exe rev-parse --is-inside-work-tree # timeout=10
>>>
>>> Fetching changes from the remote Git repository
>>>
>>>  > git.exe config remote.origin.url git@URL_REDACTED # timeout=10
>>>
>>> Fetching upstream changes from git@URL_REDACTED
>>>
>>>  > git.exe --version # timeout=10
>>>
>>>  > git.exe -c core.askpass=true fetch --tags --progress git@URL_REDACTED 
>>> +refs/heads/*:refs/remotes/origin/*
>>>
>>> ERROR: Timeout after 10 minutes
>>>
>>> ERROR : Error fetching 
>>> remote repo 'origin'
>>>
>>> Running : Allocate 
>>> node : Body : End
>>>
>>> Running: Allocate node : End
>>>
>>> Running: End of Workflow
>>>
>>> ERROR: Error fetching remote repo 'origin'
>>>
>>> Finished : FAILURE
>>>
>>>
>>>
>>> I’m wondering where the “-c core.askpass=true” came from, and figuring
>>> that it was waiting to receive a password via standard input.
>>>
>>> Is there any way, with or without the credentials plugin, to feed Git
>>> credentials to this project?
>>>
>>
>> The "-c core.askpass=true" is used to prevent the git command line call
>> from prompting for a password from stdin.  It was added in a recent
>> git-client-plugin and was a key change to enable resolution of several
>> other bugs.  I doubt very much that argument is causing an authentication
>> problem.
>>
>>
>  Thanks in advance,
>>>
>>>
>>>
>>> --Rob
>>>
>>> --
>>> This e-mail and the information, including any attachments it contains,
>>> are intended to be a confidential communication only to the person or
>>> entity to whom it is addressed and may contain information that is
>>> privileged. If the reader of this message is not the intended recipient,
>>> you are hereby notified that any dissemination, distribution or copying of
>>> this communication

Re: Git Credentials on Workflow Plugin

[Arunkumar Perumal]

Hello Mark,

When I use Git Client Plugin 1.13.0, I'm not getting -c core.askpass=true.

But when I use, 1.14.0, its using that option but you have released the 
change in 1.14.1. Could you please let me know how I can skip this 
particular step in Git Client Plugin 1.14.0

1.14.1 (Dec 27, 2014) 
   
   - Only use "-c core.askpass=true" if command line git is newer than 
   1.7.9 (don't break really old git versions unnecessarily)

1.14.0 (Dec 25, 2014) 
   
   - Update from JGit 3.5.3 to JGit 3.6.0
   -   Use command line credentials check when using command line git (issue 
   #22675 , issue #22909 
   , issue #23050 
   , issue #20533 
   )



On Wednesday, January 28, 2015 at 10:01:24 AM UTC+5:30, Mark Waite wrote:
>
> The "-c core.askpass=true" is used to prevent the git command line call 
> from prompting for a password from stdin.  It was added in a recent 
> git-client-plugin and was a key change to enable resolution of several 
> other bugs.  I doubt very much that argument is causing an authentication 
> problem.
>
> On Tue, Jan 27, 2015 at 9:15 AM, Rob Mandeville  > wrote:
>
>>  I am using:
>>
>> · Jenkins 1.580.2
>>
>> · GIT client plugin 1.15.0
>>
>> · GIT plugin 2.3.4
>>
>> · Workflow plugins 1.1
>>
>> · Credentials plugin 1.22
>>
>>  
>>
>> We use GitLab for source control and do not allow anonymous access of any 
>> kind.  We use the Credentials plugin, have put in credentials allowing us 
>> access to Git, and on our normal projects, we simply give Git these 
>> pre-loaded credentials.  Now, I’m trying to create a Workflow job.
>>
>>  
>>
>> I can’t find any doc which says how to feed credentials to Git, so I went 
>> to the credentials plugin and pulled the plugin ID from the URL.  I then 
>> wrote the following Groovy CPS DSL script (without the redactions, 
>> obviously):
>>
>>  
>>
>>  
>>
>> steps.stage('Setup')
>>
>> node('mock_builder') {
>>
>>String templateUrl = 'git@URL_REDACTED'
>>
>>steps.git(url: templateUrl, credentialsId: 'ID_REDACTED')
>>
>>sh 'echo hello world'
>>
>> }
>>
>>  
>>
>> The job gets stuck in the SCM step and exits with the following output:
>>
>>  
>>
>> Running: Setup
>>
>> Entering stage Setup
>>
>> Proceeding
>>
>> Running: Allocate node : Start
>>
>> Running on mock_builder in 
>> C:\Windows\TEMP\hudson1572436821107746068tmp\workspace\Try a Workflow
>>
>> Running: Allocate node : Body : Start
>>
>> Running: Git
>>
>>  > git.exe rev-parse --is-inside-work-tree # timeout=10
>>
>> Fetching changes from the remote Git repository
>>
>>  > git.exe config remote.origin.url git@URL_REDACTED # timeout=10
>>
>> Fetching upstream changes from git@URL_REDACTED
>>
>>  > git.exe --version # timeout=10
>>
>>  > git.exe -c core.askpass=true fetch --tags --progress git@URL_REDACTED 
>> +refs/heads/*:refs/remotes/origin/*
>>
>> ERROR: Timeout after 10 minutes
>>
>> ERROR : Error fetching 
>> remote repo 'origin'
>>
>> Running : Allocate 
>> node : Body : End
>>
>> Running: Allocate node : End
>>
>> Running: End of Workflow
>>
>> ERROR: Error fetching remote repo 'origin'
>>
>> Finished : FAILURE
>>
>>  
>>
>> I’m wondering where the “-c core.askpass=true” came from, and figuring 
>> that it was waiting to receive a password via standard input.
>>
>> Is there any way, with or without the credentials plugin, to feed Git 
>> credentials to this project?
>>
>
> The "-c core.askpass=true" is used to prevent the git command line call 
> from prompting for a password from stdin.  It was added in a recent 
> git-client-plugin and was a key change to enable resolution of several 
> other bugs.  I doubt very much that argument is causing an authentication 
> problem.
>  
>
>>  Thanks in advance,
>>
>>  
>>
>> --Rob
>>  
>> --
>> This e-mail and the information, including any attachments it contains, 
>> are intended to be a confidential communication only to the person or 
>> entity to whom it is addressed and may contain information that is 
>> privileged. If the reader of this message is not the intended recipient, 
>> you are hereby notified that any dissemination, distribution or copying of 
>> this communication is strictly prohibited. If you have received this 
>> communication in error, please immediately notify the sender and destroy 
>> the original message.
>>
>> Thank you.
>>
>> Please consider the environment before printing this email.
>>  
>> -- 
>> 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 
>> em

Re: Git Credentials on Workflow Plugin

[Timur Batyrshin]

Hi Rob,

AFAIK, git command of workflow plugin does not support that.
Use GeneralSCM for that, like described 
at 
https://github.com/jenkinsci/workflow-plugin/blob/master/scm-step/README.md#generic-scm-step.
I've defined for that a special function at the start of my workflow script:

def gitCheckout(url, branch, credentials) {
  checkout changelog: true, poll: true, scm: [$class: 'GitSCM', branches: 
[[name: branch]], userRemoteConfigs: [[credentialsId: credentials, url: 
url]]]
}

and later in code just use
gitCheckout('https://github.com/X/XX.git', "remotes/origin/master", 
"-XXX--X")

Regards,
Timur

вторник, 27 января 2015 г., 19:15:48 UTC+3 пользователь Rob Mandeville 
написал:
>
>  I am using:
>
> · Jenkins 1.580.2
>
> · GIT client plugin 1.15.0
>
> · GIT plugin 2.3.4
>
> · Workflow plugins 1.1
>
> · Credentials plugin 1.22
>
>  
>
> We use GitLab for source control and do not allow anonymous access of any 
> kind.  We use the Credentials plugin, have put in credentials allowing us 
> access to Git, and on our normal projects, we simply give Git these 
> pre-loaded credentials.  Now, I’m trying to create a Workflow job.
>
>  
>
> I can’t find any doc which says how to feed credentials to Git, so I went 
> to the credentials plugin and pulled the plugin ID from the URL.  I then 
> wrote the following Groovy CPS DSL script (without the redactions, 
> obviously):
>
>  
>
>  
>
> steps.stage('Setup')
>
> node('mock_builder') {
>
>String templateUrl = 'git@URL_REDACTED'
>
>steps.git(url: templateUrl, credentialsId: 'ID_REDACTED')
>
>sh 'echo hello world'
>
> }
>
>  
>
> The job gets stuck in the SCM step and exits with the following output:
>
>  
>
> Running: Setup
>
> Entering stage Setup
>
> Proceeding
>
> Running: Allocate node : Start
>
> Running on mock_builder in 
> C:\Windows\TEMP\hudson1572436821107746068tmp\workspace\Try a Workflow
>
> Running: Allocate node : Body : Start
>
> Running: Git
>
>  > git.exe rev-parse --is-inside-work-tree # timeout=10
>
> Fetching changes from the remote Git repository
>
>  > git.exe config remote.origin.url git@URL_REDACTED # timeout=10
>
> Fetching upstream changes from git@URL_REDACTED
>
>  > git.exe --version # timeout=10
>
>  > git.exe -c core.askpass=true fetch --tags --progress git@URL_REDACTED 
> +refs/heads/*:refs/remotes/origin/*
>
> ERROR: Timeout after 10 minutes
>
> ERROR : Error fetching 
> remote repo 'origin'
>
> Running : Allocate 
> node : Body : End
>
> Running: Allocate node : End
>
> Running: End of Workflow
>
> ERROR: Error fetching remote repo 'origin'
>
> Finished : FAILURE
>
>  
>
> I’m wondering where the “-c core.askpass=true” came from, and figuring 
> that it was waiting to receive a password via standard input.
>
> Is there any way, with or without the credentials plugin, to feed Git 
> credentials to this project?
>
>  
>
> Thanks in advance,
>
>  
>
> --Rob
>  
> --
> This e-mail and the information, including any attachments it contains, 
> are intended to be a confidential communication only to the person or 
> entity to whom it is addressed and may contain information that is 
> privileged. If the reader of this message is not the intended recipient, 
> you are hereby notified that any dissemination, distribution or copying of 
> this communication is strictly prohibited. If you have received this 
> communication in error, please immediately notify the sender and destroy 
> the original message.
>
> Thank you.
>
> Please consider the environment before printing this email.
>  

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/c2500d38-3814-42b9-9e49-446974054cd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Git Credentials on Workflow Plugin

[Mark Waite]

The "-c core.askpass=true" is used to prevent the git command line call
from prompting for a password from stdin.  It was added in a recent
git-client-plugin and was a key change to enable resolution of several
other bugs.  I doubt very much that argument is causing an authentication
problem.

On Tue, Jan 27, 2015 at 9:15 AM, Rob Mandeville <
rmandevi...@dekaresearch.com> wrote:

>  I am using:
>
> · Jenkins 1.580.2
>
> · GIT client plugin 1.15.0
>
> · GIT plugin 2.3.4
>
> · Workflow plugins 1.1
>
> · Credentials plugin 1.22
>
>
>
> We use GitLab for source control and do not allow anonymous access of any
> kind.  We use the Credentials plugin, have put in credentials allowing us
> access to Git, and on our normal projects, we simply give Git these
> pre-loaded credentials.  Now, I’m trying to create a Workflow job.
>
>
>
> I can’t find any doc which says how to feed credentials to Git, so I went
> to the credentials plugin and pulled the plugin ID from the URL.  I then
> wrote the following Groovy CPS DSL script (without the redactions,
> obviously):
>
>
>
>
>
> steps.stage('Setup')
>
> node('mock_builder') {
>
>String templateUrl = 'git@URL_REDACTED'
>
>steps.git(url: templateUrl, credentialsId: 'ID_REDACTED')
>
>sh 'echo hello world'
>
> }
>
>
>
> The job gets stuck in the SCM step and exits with the following output:
>
>
>
> Running: Setup
>
> Entering stage Setup
>
> Proceeding
>
> Running: Allocate node : Start
>
> Running on mock_builder in 
> C:\Windows\TEMP\hudson1572436821107746068tmp\workspace\Try a Workflow
>
> Running: Allocate node : Body : Start
>
> Running: Git
>
>  > git.exe rev-parse --is-inside-work-tree # timeout=10
>
> Fetching changes from the remote Git repository
>
>  > git.exe config remote.origin.url git@URL_REDACTED # timeout=10
>
> Fetching upstream changes from git@URL_REDACTED
>
>  > git.exe --version # timeout=10
>
>  > git.exe -c core.askpass=true fetch --tags --progress git@URL_REDACTED 
> +refs/heads/*:refs/remotes/origin/*
>
> ERROR: Timeout after 10 minutes
>
> ERROR : Error fetching 
> remote repo 'origin'
>
> Running : Allocate 
> node : Body : End
>
> Running: Allocate node : End
>
> Running: End of Workflow
>
> ERROR: Error fetching remote repo 'origin'
>
> Finished : FAILURE
>
>
>
> I’m wondering where the “-c core.askpass=true” came from, and figuring
> that it was waiting to receive a password via standard input.
>
> Is there any way, with or without the credentials plugin, to feed Git
> credentials to this project?
>

The "-c core.askpass=true" is used to prevent the git command line call
from prompting for a password from stdin.  It was added in a recent
git-client-plugin and was a key change to enable resolution of several
other bugs.  I doubt very much that argument is causing an authentication
problem.


>  Thanks in advance,
>
>
>
> --Rob
>
> --
> This e-mail and the information, including any attachments it contains,
> are intended to be a confidential communication only to the person or
> entity to whom it is addressed and may contain information that is
> privileged. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution or copying of
> this communication is strictly prohibited. If you have received this
> communication in error, please immediately notify the sender and destroy
> the original message.
>
> Thank you.
>
> Please consider the environment before printing this email.
>
> --
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/0A40042D85E7C84DB443060EC44B3FD36D9ACEDA91%40dekaexchange07.deka.local
> 
> .
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtFC1x1UH_6H0GyPJzMVXqx769ULJXAGk7CkjOzLfXVgNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Git Credentials on Workflow Plugin

[Rob Mandeville]

I am using:

* Jenkins 1.580.2

* GIT client plugin 1.15.0

* GIT plugin 2.3.4

* Workflow plugins 1.1

* Credentials plugin 1.22

We use GitLab for source control and do not allow anonymous access of any kind. 
 We use the Credentials plugin, have put in credentials allowing us access to 
Git, and on our normal projects, we simply give Git these pre-loaded 
credentials.  Now, I'm trying to create a Workflow job.

I can't find any doc which says how to feed credentials to Git, so I went to 
the credentials plugin and pulled the plugin ID from the URL.  I then wrote the 
following Groovy CPS DSL script (without the redactions, obviously):


steps.stage('Setup')
node('mock_builder') {
   String templateUrl = 'git@URL_REDACTED'
   steps.git(url: templateUrl, credentialsId: 'ID_REDACTED')
   sh 'echo hello world'
}

The job gets stuck in the SCM step and exits with the following output:


Running: Setup

Entering stage Setup

Proceeding

Running: Allocate node : Start

Running on mock_builder in 
C:\Windows\TEMP\hudson1572436821107746068tmp\workspace\Try a Workflow

Running: Allocate node : Body : Start

Running: Git

 > git.exe rev-parse --is-inside-work-tree # timeout=10

Fetching changes from the remote Git repository

 > git.exe config remote.origin.url git@URL_REDACTED # timeout=10

Fetching upstream changes from git@URL_REDACTED

 > git.exe --version # timeout=10

 > git.exe -c core.askpass=true fetch --tags --progress git@URL_REDACTED 
 > +refs/heads/*:refs/remotes/origin/*

ERROR: Timeout after 10 minutes

ERROR: Error fetching 
remote repo 'origin'

Running: Allocate node : 
Body : End

Running: Allocate node : End

Running: End of Workflow

ERROR: Error fetching remote repo 'origin'

Finished: FAILURE

I'm wondering where the "-c core.askpass=true" came from, and figuring that it 
was waiting to receive a password via standard input.
Is there any way, with or without the credentials plugin, to feed Git 
credentials to this project?

Thanks in advance,

--Rob


This e-mail and the information, including any attachments it contains, are 
intended to be a confidential communication only to the person or entity to 
whom it is addressed and may contain information that is privileged. If the 
reader of this message is not the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, please 
immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/0A40042D85E7C84DB443060EC44B3FD36D9ACEDA91%40dekaexchange07.deka.local.
For more options, visit https://groups.google.com/d/optout.