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 <[email protected] > <javascript:>> 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.<init>(Command.java:67) >> at hudson.remoting.Command.<init>(Command.java:50) >> at hudson.remoting.UnexportCommand.<init>(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 <[email protected] >>> > 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/git949589945555918016.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 < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 >>>>>>> <http://issues.jenkins-ci.org/browse/JENKINS-22675>, issue #22909 >>>>>>> <http://issues.jenkins-ci.org/browse/JENKINS-22909>, issue #23050 >>>>>>> <http://issues.jenkins-ci.org/browse/JENKINS-23050>, issue #20533 >>>>>>> <http://issues.jenkins-ci.org/browse/JENKINS-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 < >>>>>>>> [email protected]> 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 <http://stacktrace.jenkins-ci.org/search?query=ERROR>: Error >>>>>>>>> fetching remote repo 'origin' >>>>>>>>> >>>>>>>>> Running <http://stacktrace.jenkins-ci.org/search?query=Running>: >>>>>>>>> Allocate node : Body : End >>>>>>>>> >>>>>>>>> Running: Allocate node : End >>>>>>>>> >>>>>>>>> Running: End of Workflow >>>>>>>>> >>>>>>>>> ERROR: Error fetching remote repo 'origin' >>>>>>>>> >>>>>>>>> Finished <http://stacktrace.jenkins-ci.org/search?query=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 [email protected]. >>>>>>>> >>>>>>>> >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/jenkinsci-users/0A40042D85 >>>>>>>>> E7C84DB443060EC44B3FD36D9ACEDA91%40dekaexchange07.deka.local >>>>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/0A40042D85E7C84DB443060EC44B3FD36D9ACEDA91%40dekaexchange07.deka.local?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> 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]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/jenkinsci-users/29112111-e >>>>>>> 2f5-4d62-b916-011e72dbfae2%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/29112111-e2f5-4d62-b916-011e72dbfae2%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>>> 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]. >>>> >>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/jenkinsci-users/c461ac80-a0ef-436c-94c9- >>>> 906f13fc1b4f%40googlegroups.com >>>> <https://groups.google.com/d/msgid/jenkinsci-users/c461ac80-a0ef-436c-94c9-906f13fc1b4f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/3f8c619c-a7ba-4f50-8e2f-51b201673caf%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-users/3f8c619c-a7ba-4f50-8e2f-51b201673caf%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/9b738b5c-14f9-487f-9fa6-1cea4e1bf2b6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
