Can't configure Git user.name and user.email

301 views
Skip to first unread message

Mike Dalrymple

unread,
Sep 29, 2015, 6:35:54 PM9/29/15
to job-dsl-plugin
I'm attempting to set the Git user.name and user.email parameters for a project as seen here:

When I set that directly in Jenkins, I get a config.xml snippet like the following:

    <extensions>
     
<hudson.plugins.git.extensions.impl.UserIdentity>
       
<name>FooUser</name>
       
<email>f...@example.com</email>
     
</hudson.plugins.git.extensions.impl.UserIdentity>
   
</extensions>

Attempting to recreate that configuration using the job-dsl following the 'example-3' in the git API Docs, gets me:

        <extensions>
           
<hudson.plugins.git.extensions.impl.UserIdentity>
               
<gitConfigName>FooUser</gitConfigName>
               
<gitConfigEmail>f...@example.com</gitConfigEmail>
           
</hudson.plugins.git.extensions.impl.UserIdentity>
       
</extensions>

If I try to manually set that using this configure block

configure { node ->
    node
/ 'extensions' / 'hudson.plugins.git.extensions.impl.UserIdentity' << {
        name
('FooUser')
        email
('f...@example.com')
   
}
}


I get the expected XML results in the Sandbox but when I attempt to generate it using the gradle-jenkins-plugin I get the warning Warning: doCall is deprecated and the Job/Project gets the name 'FooUser' and user.name/user.email are empty.


I feel like I'm stuck between two issues, 1) gitConfigName and gitConfigEmail don't work or they're not intended for what I'm using. 2) name() is getting picked up by the gradle-jenkins-plugin so I can't manually configure those fields.


What are gitConfigName and gitConfigEmail for?


P.S. Is there an issue tracker for this project? 


Thanks for any assistance!






milki milk

unread,
Sep 30, 2015, 1:18:11 AM9/30/15
to job-dsl-plugin
You probably have an different version of the git plugin.

From what I can tell, the change from gitConfigName to name probably happened with this commit: https://github.com/jenkinsci/git-plugin/commit/495f2df2b42e16193de690b76d2cf2e7c543ee42

Daniel Spilker

unread,
Sep 30, 2015, 2:13:36 PM9/30/15
to job-dsl...@googlegroups.com
You are probably using an older version of the DSL plugin. In that case you are calling the job's name method from the configure block. Newer versions of the plugin do not have a name method, that's why it works on the playground with the latest version.

To avoid to call methods from the outer scope, call the methods on the closure's delegate, e.g.

job('example') {
  scm {
    git {

      configure { node ->
        node / 'extensions' / 'hudson.plugins.git.extensions.impl.UserIdentity' << {
          delegate.name('FooUser')
          email('f...@example.com')
        }
      }
    }
  }
}


Daniel

On Wed, Sep 30, 2015 at 7:18 AM, milki milk <nites...@gmail.com> wrote:
You probably have an different version of the git plugin.

From what I can tell, the change from gitConfigName to name probably happened with this commit: https://github.com/jenkinsci/git-plugin/commit/495f2df2b42e16193de690b76d2cf2e7c543ee42

--
You received this message because you are subscribed to the Google Groups "job-dsl-plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to job-dsl-plugi...@googlegroups.com.
To post to this group, send email to job-dsl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/074f7760-2920-4865-a36d-fec6b68e4cb9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Mike Dalrymple

unread,
Sep 30, 2015, 2:34:07 PM9/30/15
to job-dsl-plugin
Updating my script to use the delegate results in the same errors as the original post. 

I'm using the gradle-jenkins-plugin version 1.3.1 and I've swapped in the job-dsl-core dependency version 1.35 (default dependency version is 1.34).  When I try going beyond 1.35 I start getting transitive dependency problems with com.google.common.collect.Maps.

I'm currently working around this issue by setting the user.name and user.email options on the Jenkins user at an OS level so I'm able to carry on, it just adds another step to the base server setup.
Reply all
Reply to author
Forward
0 new messages