[
https://issues.jenkins-ci.org/browse/JENKINS-13356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Günther updated JENKINS-13356:
-----------------------------------
Summary: Git fast remote polling always triggers build when missing
locale (was: Git fast remote polling always triggered, missing locale)
Description:
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.
was:
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.
> 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
