Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-9016

Git creates usernames based on 'name' not the email.

    Details

    • Similar Issues:

      Description

      I realize mapping git author/commit users back to Jenkin's users is pain, but perhaps it could be done a little better.

      Some ideas:

      • Try looking up a user's email and comparing that.
      • Using the user portion from the email (e.g. someuser@example.com becomes someuser).
      • Looking up the user's email in LDAP, if LDAP is being used.

      The last would be ideal for us.

      Ciao!

        Attachments

          Issue Links

            Activity

            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            src/main/java/hudson/plugins/git/GitChangeSet.java
            http://jenkins-ci.org/commit/git-plugin/3607d2ec90f69edcf8cedfcb358ce19a980b8f1a
            Log:
            [FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: src/main/java/hudson/plugins/git/GitChangeSet.java http://jenkins-ci.org/commit/git-plugin/3607d2ec90f69edcf8cedfcb358ce19a980b8f1a Log: [FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead.
            Hide
            dogfood dogfood added a comment -

            Integrated in plugins_git-plugin #119
            [FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead.

            Andrew Bayer : 3607d2ec90f69edcf8cedfcb358ce19a980b8f1a
            Files :

            • src/main/java/hudson/plugins/git/GitChangeSet.java
            Show
            dogfood dogfood added a comment - Integrated in plugins_git-plugin #119 [FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead. Andrew Bayer : 3607d2ec90f69edcf8cedfcb358ce19a980b8f1a Files : src/main/java/hudson/plugins/git/GitChangeSet.java
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            src/test/java/hudson/plugins/git/AbstractGitTestCase.java
            http://jenkins-ci.org/commit/git-plugin/12515a33b7ae0e8030fbc61575e6cd445850ceb2
            Log:
            Fixing test failures due to JENKINS-9016 fix.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: src/test/java/hudson/plugins/git/AbstractGitTestCase.java http://jenkins-ci.org/commit/git-plugin/12515a33b7ae0e8030fbc61575e6cd445850ceb2 Log: Fixing test failures due to JENKINS-9016 fix.
            Hide
            joel Joel Hough added a comment -

            I'm still having issues with this.
            In my setup, we use ldap for authentication. The ldap username has almost no similarity to the author name or email in our git commits (we use full and proper "Firstname Lastname <Firstname.Lastname@Companyname.com>" for that).
            What would work is searching for existing users by email address rather than using the email segment as a username, since the ldap plugin does properly set the email field to the same address as is listed in the git commit (assuming case insensitivity).

            Show
            joel Joel Hough added a comment - I'm still having issues with this. In my setup, we use ldap for authentication. The ldap username has almost no similarity to the author name or email in our git commits (we use full and proper "Firstname Lastname <Firstname.Lastname@Companyname.com>" for that). What would work is searching for existing users by email address rather than using the email segment as a username, since the ldap plugin does properly set the email field to the same address as is listed in the git commit (assuming case insensitivity).
            Hide
            dumbbell Jean-Sébastien Pédron added a comment - - edited

            I agree with Joel's comment.

            In our setup, only users changing their full name in Jenkins to match the one in Git have their commits associated. Other people have two "accounts": the one they use to authenticate (LDAP) and the one automatically created with Git commits.

            Using the e-mail address to do the mapping seems to be a better solution.

            Show
            dumbbell Jean-Sébastien Pédron added a comment - - edited I agree with Joel's comment. In our setup, only users changing their full name in Jenkins to match the one in Git have their commits associated. Other people have two "accounts": the one they use to authenticate (LDAP) and the one automatically created with Git commits. Using the e-mail address to do the mapping seems to be a better solution.
            Hide
            vstone Jan Vansteenkiste added a comment - - edited

            I have created some initial code on this subject. The only question that remains is whether the plugin is the right place for my UserEmailResolver.
            I also had some troubles getting the tests going and had to add a newer jenkins-core, ui-samples-plugin, jenkins-test-harness and javadoc to the dependencies.

            https://github.com/vStone/git-plugin/commit/63612268d832edc7a77d0be55e650e31fc5442a9

            Show
            vstone Jan Vansteenkiste added a comment - - edited I have created some initial code on this subject. The only question that remains is whether the plugin is the right place for my UserEmailResolver. I also had some troubles getting the tests going and had to add a newer jenkins-core, ui-samples-plugin, jenkins-test-harness and javadoc to the dependencies. https://github.com/vStone/git-plugin/commit/63612268d832edc7a77d0be55e650e31fc5442a9
            Hide
            drzewo Dominik Drzewiecki added a comment -

            In my setup I have users authenticated against corporate Active Directory, which works nice along with LDAP email plugin (email addresses get resolved correctly). User ids look something like 123456, and as such are defined in Global Security. Real user names do get resolved correctly from those numeric ids.
            Unfortunatelly, when it comes to build changes list of the git based projects, the real user names do not get resolved correctly as they do not contain those numeric ids any more. For the commiter/author "Dominik Drzewiecki <dominik.drzewiecki@acme.com>" which is a concatenation of git user.name and user.email configuration parameters I get the changelog entry commited by dominik.drzewiecki which cannot be futher resolved either against AD (id) or LDAP (email). It seems that Jan's patch that adds one extra resolution step would do the trick.

            Show
            drzewo Dominik Drzewiecki added a comment - In my setup I have users authenticated against corporate Active Directory, which works nice along with LDAP email plugin (email addresses get resolved correctly). User ids look something like 123456, and as such are defined in Global Security. Real user names do get resolved correctly from those numeric ids. Unfortunatelly, when it comes to build changes list of the git based projects, the real user names do not get resolved correctly as they do not contain those numeric ids any more. For the commiter/author "Dominik Drzewiecki <dominik.drzewiecki@acme.com>" which is a concatenation of git user.name and user.email configuration parameters I get the changelog entry commited by dominik.drzewiecki which cannot be futher resolved either against AD (id) or LDAP (email). It seems that Jan's patch that adds one extra resolution step would do the trick.
            Hide
            nnutter Nathan Nutter added a comment - - edited

            The only two "modes" at the moment (v2.0) seem to be either user.name or user.email not the username from user.email? The latter being the suggested default "mode" in v1.1.7:

            If no Jenkins user is found for a commit's user.name value, strip the username from "username@domain.com" from the user.email value and use that instead.

            We want users to be associated with just their username not their full email and not their user.name so that other things can automatically work, e.g. the Jabber Plugin. Also, the users log in, via LDAP, with just their username.

            Show
            nnutter Nathan Nutter added a comment - - edited The only two "modes" at the moment (v2.0) seem to be either user.name or user.email not the username from user.email? The latter being the suggested default "mode" in v1.1.7: If no Jenkins user is found for a commit's user.name value, strip the username from "username@domain.com" from the user.email value and use that instead. We want users to be associated with just their username not their full email and not their user.name so that other things can automatically work, e.g. the Jabber Plugin. Also, the users log in, via LDAP, with just their username.
            Hide
            epkabeg Andréas Berg added a comment - - edited

            The unique identifier in git is the e-mail address so matching towards a Jenkins account on user name is really bad. In some cases, like for example push-review tests with Gerrit, you do not need to match to a Jenkins account at all, just use the e-mail address in the commit when sending feedback.

            Option #1 (Try looking up a user's email and comparing that.) is definitely the way this should be implemented.
            Option #3 (Looking up the user's email in LDAP, if LDAP is being used.) would be a great bonus.

            Option #2 (Using the user portion from the email (e.g. someuser@example.com becomes someuser).) is just as bad is matching on user name and solves nothing.

            We are a big company with a lot of people, some do have the exact same names so now we have users getting e-mail feedback on git commits they are not the author of.

            Show
            epkabeg Andréas Berg added a comment - - edited The unique identifier in git is the e-mail address so matching towards a Jenkins account on user name is really bad. In some cases, like for example push-review tests with Gerrit, you do not need to match to a Jenkins account at all, just use the e-mail address in the commit when sending feedback. Option #1 (Try looking up a user's email and comparing that.) is definitely the way this should be implemented. Option #3 (Looking up the user's email in LDAP, if LDAP is being used.) would be a great bonus. Option #2 (Using the user portion from the email (e.g. someuser@example.com becomes someuser).) is just as bad is matching on user name and solves nothing. We are a big company with a lot of people, some do have the exact same names so now we have users getting e-mail feedback on git commits they are not the author of.
            Hide
            dageissl Daniel Geißler added a comment -

            Problem still persists.
            In my company users are uniquely identified by their email adress not their user.name, so extracting the user name from the email does not work either. Any plans when to fix that?

            Show
            dageissl Daniel Geißler added a comment - Problem still persists. In my company users are uniquely identified by their email adress not their user.name, so extracting the user name from the email does not work either. Any plans when to fix that?
            Hide
            renescheibe René Scheibe added a comment -

            I have seen that the issue had some activity recently. (I came here due to JENKINS-43178.)

            I agree with Andréas Berg and Joel Hough. I would really be happy if the issue could be fixed as proposed in option #1 and #3.

            Btw. there is already this global plugin option that uses the full email address:
            Create new accounts based on author/committer's email
            As git changelog is parsed to identify authors/committers and populate Jenkins user database, use email as ID for new users.

            Show
            renescheibe René Scheibe added a comment - I have seen that the issue had some activity recently. (I came here due to JENKINS-43178 .) I agree with Andréas Berg and Joel Hough . I would really be happy if the issue could be fixed as proposed in option #1 and #3. Btw. there is already this global plugin option that uses the full email address: Create new accounts based on author/committer's email As git changelog is parsed to identify authors/committers and populate Jenkins user database, use email as ID for new users.
            Hide
            dageissl Daniel Geißler added a comment -

            With the recent security fixes (e.g. JENKINS-43178) the situation is getting even worse.

            Looking up a user based on it's configured email-address should solve so many problems.

            Expecting to have the login user names matching exactly the mail adress before the @ is just too restrictive. Guess someone changing it's mail but keeping it's account or like in my company having short login names (coming from ldap) contrary to long mail addresses.

            Andrew Bayer please consider raising the priority of this task!

            Show
            dageissl Daniel Geißler added a comment - With the recent security fixes (e.g.  JENKINS-43178 ) the situation is getting even worse. Looking up a user based on it's configured email-address should solve so many problems. Expecting to have the login user names matching exactly the mail adress before the @ is just too restrictive. Guess someone changing it's mail but keeping it's account or like in my company having short login names (coming from ldap) contrary to long mail addresses. Andrew Bayer please consider raising the priority of this task!
            Hide
            bherb Benjamin Herbert added a comment -

            I second the Option #1 (and #3) above.

            We are authenticating against LDAP and have rather arbitrary Jenkins user id s- e.g. fuu12bar5.

            The only thing the "real" LDAP users and the git users have in common is the email address (if you are willing to compare it case insensitive).

            Is this the right part of the code?
            https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L387

            There is a really old pull request, mentioned in this comment, might this be still useful?

             

            Show
            bherb Benjamin Herbert added a comment - I second the Option #1 (and #3) above. We are authenticating against LDAP and have rather arbitrary Jenkins user id s- e.g. fuu12bar5. The only thing the "real" LDAP users and the git users have in common is the email address (if you are willing to compare it case insensitive). Is this the right part of the code? https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L387 There is a really old pull request, mentioned in this comment , might this be still useful?  
            Hide
            jose_camacho Jose Camacho added a comment -

            I came to the situation described by others here, in our case jenkins users being handled using Active Directory (AD) and commit information coming from GIT (Bitbucket). For a user with my username (Jose Camacho), commit information from GIT included in "Author" part would have the username defined as jose.camacho but users in AD are created using acronyms like jocam (for jose camacho).

            My Email address is matched with both users (jose.camacho and jocam), and when trying to send out emails to me, it detects that the user name is jose.camacho (and not jocam!) and when using the realm validation mechanism (AD), AD says "not existing user" and the message "Not sending mail to unregistered user" appears.

            For the options that Andréas Berg suggested, I also second Option #1: If there is any kind of user with that email address, why should it be declared as "unregister user"?

            – Workaround

            Anyway, we are sending Emails from Jenkinsfile using emailext and we did not want to change that way of using Jenkins so we are using right now a "workaround".

            We know that the Emails information coming from GIT is correct (close, controled environment) so we disable the "not sending mail to unregistered user" by using a variable included in the EmailExt plugin version 2.58, introducing following code:

            def currenVal = RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS

            RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS  = true

            // Send Email with emailext

            RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS = currenVal

            (this needs to include import hudson.plugins.emailext.plugins.recipients.* and also needs a securiy confirmation)

            I know, it is not the better solution, but it works. Hope this helps anyone looking for a workaround.

            Show
            jose_camacho Jose Camacho added a comment - I came to the situation described by others here, in our case jenkins users being handled using Active Directory (AD) and commit information coming from GIT (Bitbucket). For a user with my username (Jose Camacho), commit information from GIT included in "Author" part would have the username defined as jose.camacho but users in AD are created using acronyms like jocam (for jose camacho). My Email address is matched with both users (jose.camacho and jocam), and when trying to send out emails to me, it detects that the user name is jose.camacho (and not jocam!) and when using the realm validation mechanism (AD), AD says "not existing user" and the message "Not sending mail to unregistered user" appears. For the options that  Andréas Berg  suggested, I also second Option #1: If there is any kind of user with that email address, why should it be declared as "unregister user"? – Workaround Anyway, we are sending Emails from Jenkinsfile using emailext and we did not want to change that way of using Jenkins so we are using right now a "workaround". We know that the Emails information coming from GIT is correct (close, controled environment) so we disable the "not sending mail to unregistered user" by using a variable included in the EmailExt plugin version 2.58, introducing following code: def currenVal = RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS  = true // Send Email with emailext RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS = currenVal (this needs to include import hudson.plugins.emailext.plugins.recipients.* and also needs a securiy confirmation) I know, it is not the better solution, but it works. Hope this helps anyone looking for a workaround.
            Hide
            dageissl Daniel Geißler added a comment - - edited

            Jose Camacho we have a very similar setup in my company. We also see that multiple users with the same email are created (one from AD when the user loges in, the other from git plugin).

            What we found was that having the git authors name matching the AD displayName seems to associate the users correctly (that can be seen in the projects changes too). If i remember correctly, when you are using Bitbucket with AD, you can enforce that name matching in all commits.

            Still a matching based on the email adress would be so much more convenient.

             

            EDIT: rechecked the association and it seems to work only in special cases, that i have to investigate further, as of today we are stuck to the system property to allow everything too.

            Show
            dageissl Daniel Geißler added a comment - - edited Jose Camacho we have a very similar setup in my company. We also see that multiple users with the same email are created (one from AD when the user loges in, the other from git plugin). What we found was that having the git authors name matching the AD displayName seems to associate the users correctly (that can be seen in the projects changes too). If i remember correctly, when you are using Bitbucket with AD, you can enforce that name matching in all commits. Still a matching based on the email adress would be so much more convenient.   EDIT: rechecked the association and it seems to work only in special cases, that i have to investigate further, as of today we are stuck to the system property to allow everything too.
            Hide
            swf Yves Schumann added a comment -

            We struggle on this issue too and in my opinion this ist not a minor issue, it's more an incident! Actually the issue is some kind of a show stopper as the user did not receive proper notifications anymore.

            Show
            swf Yves Schumann added a comment - We struggle on this issue too and in my opinion this ist not a minor issue, it's more an incident ! Actually the issue is some kind of a show stopper as the user did not receive proper notifications anymore.
            Hide
            lemairea Antoine Le Maire added a comment -

            We also struggle on this issue, any progress ?

            Show
            lemairea Antoine Le Maire added a comment - We also struggle on this issue, any progress ?
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: George
            Path:
            src/main/java/hudson/plugins/emailext/ExtendedEmailPublisherDescriptor.java
            src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java
            src/main/resources/hudson/plugins/emailext/ExtendedEmailPublisher/global.groovy
            src/main/webapp/help/globalConfig/allowUnregistered.html
            http://jenkins-ci.org/commit/email-ext-plugin/19081b2aa3d32c479125b538c545fdd3065960f8
            Log:
            JENKINS-43268 adding global checkbox to allow sending to unregistered emails. This is a workaround to a SCM plugin issue, like JENKINS-9016 and probably others (#161)

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: George Path: src/main/java/hudson/plugins/emailext/ExtendedEmailPublisherDescriptor.java src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java src/main/resources/hudson/plugins/emailext/ExtendedEmailPublisher/global.groovy src/main/webapp/help/globalConfig/allowUnregistered.html http://jenkins-ci.org/commit/email-ext-plugin/19081b2aa3d32c479125b538c545fdd3065960f8 Log: JENKINS-43268 adding global checkbox to allow sending to unregistered emails. This is a workaround to a SCM plugin issue, like JENKINS-9016 and probably others (#161)
            Hide
            patrickv Patrick Van Brussel added a comment -

            Would it be possible to have some kind of 'domain filter' when you enable the 'Allow sending to unregistered users' checkbox?

            For instance: allow sending mails to contributers to a git repo that don't have a Jenkins account, but that do have an email address set up that ends with '@domain.com'.

            This would be interesting so that when we're using open source git(hub) repositories we don't accidentally sent out mails to the contributers there, when one of our builds fail.

            Show
            patrickv Patrick Van Brussel added a comment - Would it be possible to have some kind of 'domain filter' when you enable the 'Allow sending to unregistered users' checkbox? For instance: allow sending mails to contributers to a git repo that don't have a Jenkins account, but that do have an email address set up that ends with '@domain.com'. This would be interesting so that when we're using open source git(hub) repositories we don't accidentally sent out mails to the contributers there, when one of our builds fail.
            Hide
            brianjmurrell Brian J Murrell added a comment -

            Can't the e-mail address(es) in the commit message be used to find Jenkins security realm users?

            The e-mail address in my commit messages is the same as the e-mail address associated with my Jenkins account.  Why can those not be matched up?

            Show
            brianjmurrell Brian J Murrell added a comment - Can't the e-mail address(es) in the commit message be used to find Jenkins security realm users? The e-mail address in my commit messages is the same as the e-mail address associated with my Jenkins account.  Why can those not be matched up?

              People

              • Assignee:
                Unassigned
                Reporter:
                docwhat Christian Höltje
              • Votes:
                35 Vote for this issue
                Watchers:
                44 Start watching this issue

                Dates

                • Created:
                  Updated: