[JIRA] (JENKINS-48357) Binary Compatibility between JIRA Plugin and Apache HttpComponents Client 4.x API

[mark.earl.wa...@gmail.com (JIRA)]

Title: Message Title

Mark Waite commented on JENKINS-48357   Re: Binary Compatibility between JIRA Plugin and Apache HttpComponents Client 4.x API Tibor Digana thanks for investigating further. Your efforts are appreciated very much! Your questions with my answers following each question: How credentials are passed to these commands and each of them? The git rev-list command does not require credentials. None are provided to it. Commands which need credentials like fetch and ls-remote receive them through temporary files identified by environment variables. Credentials for http and https repository URL's are written to a temporary file in the form of a response script. The name of the temporary file is assigned to the environment variables GIT_ASKPASS and SSH_ASKPASS. Command line git calls that temporary file and the temporary file responds to the command line git prompts for username and password. Credentials for ssh repository URL's are written to a temporary file. The name of the temporary file is assigned to the environment variable SSH_ASKPASS. The path to the ssh command is assigned to the environment variable GIT_SSH. The value ssh is assigned to the environment variable GIT_SSH_VARIANT. Command line git uses those environment variables to find the temporary files for authentication. Can we see them and is this real command executed in sub-process? No, they are not shown to users. Showing them to users would expose credentials to users who should not see them. Yes, command line git executes in a subprocess of the Jenkins Java process. The temporary file is executed in a subprocess of command line git so that it can provide the credential responses (http/https) or the ssh connection (ssh). Is Git running in a non-interactive mode? The git plugin attempts to run git in non-interactive mode if the command line git version is new enough to support non-interactive mode. For command line git versions 2.3 and newer, the git plugin sets the environment variable GIT_TERMINAL_PROMPT=false. If running on Windows, it also sets the environment variable GCM_INTERACTIVE=false. Can we detect that Git is interactively asking for some input on STD/IN? The plugin does not detect that git is interactively asking for input on stdin. I don't know any technique to do that.  The timeout option was added to commands which require authentication specifically because there was not a way to detect command line git was waiting for input. Can we see std/err as well as std/out in the console including the error code returned by the sub-process? Yes, we can see stdout and stderr outputs and the subprocess error code. When the git plugin prints an exception from command line git, it includes stderr and stdout of the command in the exception message. Why timeout 10 minutes is not applied however it is seen in the console log after the command (# timeout=10)? I suspect that the command completed and control has returned from the git plugin to some other part of Jenkins. The timeout was not applied because command line git had returned and job execution continued in other parts of Jenkins.  The diagnostics I inserted into the patched plugin will confirm or refute that suspicion. Add Comment   This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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 jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.