Running jenkins in kubernetes I get this error during a build/pipelineJob (where I commit, tag, release):
09:10:08 Committer identity unknown
09:10:08
09:10:08 *** Please tell me who you are.
09:10:08
09:10:08 Run
09:10:08
09:10:08 git config --global user.email "you@example.com"
09:10:08 git config --global user.name "Your Name"
09:10:08
09:10:08 to set your account's default identity.
09:10:08 Omit --global to set the identity only in this repository.
09:10:08
09:10:08 fatal: unable to auto-detect email address (got 'jenkins@jenkins-agent-2994b93a-2852-43df-bdaa-cce2e70352fd-n05kg-l35fr.(none)')
even though I have configured user.name and user.email in the git plugin (Global configuration)
Any suggestions on how to pick up that information in the build agent?
UPDATE: Potentially related to this (5 year old!) bug:
https://issues.jenkins.io/browse/JENKINS-46052
Use a shell, batch, or powershell command to configure the git committer user name and git committer email address.
If that’s not palatable, you can wrap the sh commands in a withEnv step that provides the values of GIT_COMMITER_NAME and GIT_COMMITER_EMAIL. See this tutorial blog post for more details.
If that’s not palatable, you can use the config file provider plugin to deliver that file as a configuration file.
If that’s not palatable, you can use the label verifier plugin to run a shell script on each agent when it starts. In that script, if the git committer user name and email address are not the desired value, set them to the desired value.
Hm I would prefer not to repeat that configuration in each of my pipelines. I would also like to avoid having it in a shared library function that will only work for those pipelines that remembers to call that function.
A “low level” hack is to just have it set in dockerfile I use for building the jenkins agents.
I believe a good solution would be to configure this in e.g. JCASC under e.g. global properties which I am now investigating.
UPDATE: Setting those ENVs thorugh the Global Properties:
Does not work - I get the same/original error 
If you use the label verifier workaround, you can refer to my JCasC example that checks the command line git version label that I’ve applied to the agent matches the version of command line git on the agent.
