[ 
https://issues.jenkins-ci.org/browse/JENKINS-13356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161296#comment-161296
 ] 

SCM/JIRA link daemon commented on JENKINS-13356:
------------------------------------------------

Code changed in jenkins
User: Marc Guenther
Path:
 src/main/java/hudson/plugins/git/GitAPI.java
http://jenkins-ci.org/commit/git-plugin/46849405805e5e07448150cd099f73a54cfcdc7b
Log:
  [JENKINS-13356] ignore stderr when launching external git command



                
> Git fast remote polling always triggers build when missing locale
> -----------------------------------------------------------------
>
>                 Key: JENKINS-13356
>                 URL: https://issues.jenkins-ci.org/browse/JENKINS-13356
>             Project: Jenkins
>          Issue Type: Bug
>          Components: git
>            Reporter: Marc Günther
>            Assignee: Nicolas De Loof
>            Priority: Minor
>
> Symptom:
> All jobs which had fast remote polling enabled triggered on every change in 
> their repository, even if it was on an unrelated branch.
> Cause:
> Fast remote polling issues a {{git ls-remote -h <repo> <branch>}} command. 
> The output of this command is supposed to be the sha hash of the last commit, 
> but in our case it was:
> {{bash: warning: setlocale: LC_ALL: cannot}}
> Explanation:
> We have some slaves that use a german locale. This locale does not exist on 
> the Git repository server nor on the Jenkins server. Installing it on the 
> Jenkins server had no effect, as the above warning comes from the Git 
> repository server.
> Quick fix:
> Install the missing locale on the both servers.
> Solution:
> Installing locales on some server should not be required. Either ignore 
> stderr when issuing the {{git ls-remote}} command, or manipulate the passed 
> in environment to something that does not cause side effects like this.
> Question:
> Why is the environment from the slave used on the server when doing the 
> polling? {{LC_ALL}} is not set on our Jenkins server, so this definitely 
> comes from a slave. I also notice that variables like HOME, USER, DISPLAY are 
> set to values which make no sense on the server, and can lead to more 
> problems like this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to