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

Plugin doesn't use account's identity (our case 12395)

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Plugin cannot commit ("Failed to merge changes. Error message: *** Please tell me who you are").

      It doesn't use the Git plugin Global config neither it uses project specific user name/email address.

      Which account info is used by the plugin? Should I add a '.gitconfig' file?

        Attachments

          Issue Links

            Activity

            Hide
            bue Bue Petersen added a comment -

            Currently the git plugin can use the credentials plugin, and authentication it provides. We do not "inherit" those, and the pretested integration plugin requires to be "already" authenticated. Eg. by the user it runs under have exchanged ssh-keys with the git server. Or by specifying a git config file.

            Can you clariy "account's identity" ?

            Show
            bue Bue Petersen added a comment - Currently the git plugin can use the credentials plugin, and authentication it provides. We do not "inherit" those, and the pretested integration plugin requires to be "already" authenticated. Eg. by the user it runs under have exchanged ssh-keys with the git server. Or by specifying a git config file. Can you clariy "account's identity" ?
            Hide
            alfernie Al Ferguson added a comment -

            This is the exact message I get:

            *********************************************************************
            10:38:15 Failed to merge changes. Error message below
            10:38:15
            10:38:15 *** Please tell me who you are.
            10:38:15
            10:38:15 Run
            10:38:15
            10:38:15 git config --global user.email "you@example.com"
            10:38:15 git config --global user.name "Your Name"
            10:38:15
            10:38:15 to set your account's default identity.
            10:38:15 Omit --global to set the identity only in this repository.
            10:38:15
            10:38:15 fatal: empty ident <tomcat6@stc3-asvd-07.alogient.com
            10:38:15 > not allowed
            *********************************************************************

            It doesn't use what I set up in :

            • Global Jenkins: Configure, Source Code Management, Advanced, "Config user.name Value" and "Config user.email Value"
            • Job specific: Configure, Source Code Management, Additional Behaviours, Custom user name/e-mail address, user.name and user.address

            That's what I referred to as "account's identity".

            For the moment, I just need a workaround. You mentioned a git config file, will it work? Any other option?

            Show
            alfernie Al Ferguson added a comment - This is the exact message I get: ********************************************************************* 10:38:15 Failed to merge changes. Error message below 10:38:15 10:38:15 *** Please tell me who you are. 10:38:15 10:38:15 Run 10:38:15 10:38:15 git config --global user.email "you@example.com" 10:38:15 git config --global user.name "Your Name" 10:38:15 10:38:15 to set your account's default identity. 10:38:15 Omit --global to set the identity only in this repository. 10:38:15 10:38:15 fatal: empty ident <tomcat6@stc3-asvd-07.alogient.com 10:38:15 > not allowed ********************************************************************* It doesn't use what I set up in : Global Jenkins: Configure, Source Code Management, Advanced, "Config user.name Value" and "Config user.email Value" Job specific: Configure, Source Code Management, Additional Behaviours, Custom user name/e-mail address, user.name and user.address That's what I referred to as "account's identity". For the moment, I just need a workaround. You mentioned a git config file, will it work? Any other option?
            Hide
            bue Bue Petersen added a comment -

            If you have access to your build slave, you should configure the user that the Jenkins slave run as to be able to push to your repositories (and read).

            I usually exchange ssh-keys with my repos, just if it was my daily user.

            I know it might be easier some times to use the Credential Plugin, but make the local user have access make other things works easily also. Eg. scripts.

            If you can run git commands, including push in a execute shell build step, your authentication works.

            Hope this helps.

            Show
            bue Bue Petersen added a comment - If you have access to your build slave, you should configure the user that the Jenkins slave run as to be able to push to your repositories (and read). I usually exchange ssh-keys with my repos, just if it was my daily user. I know it might be easier some times to use the Credential Plugin, but make the local user have access make other things works easily also. Eg. scripts. If you can run git commands, including push in a execute shell build step, your authentication works. Hope this helps.
            Hide
            alfernie Al Ferguson added a comment - - edited

            Thanks Bue.

            There's something I don't understand, maybe related to the branching model.

            We develop our stories on separate feature branches, then we create pull requests to merge to our 'development' branch (The process to merge with the 'master' branch is not part of our development process, actually this merge comes later in our delivery process).

            When I installed the plugin, I did some tests on brand new branches: 'dev' and 'int'. It worked! The plugin did not attempt to make a new commit, it only applied existing 'dev' commits on 'int'.

            Since my tests were successful, I decided to delete my temporary branches and configure the plugin to build our existing 'development' branch and to merge within new 'integration' branch.

            Since that time we have the interesting situation described in this ticket.

            Why does the plugin try to perform an additional commit now it is configured on our real 'development' branch?

            Should the 'integration' branch be created in advance in the repository? If so, what must be the parent of the 'integration' branch?

            master: do not touch
            development: where developers' pull requests are merged
            story/**: features branches
            maintenance/**: guess
            integration: you tell me

            I want your plugin to build 'development' and, if successful, to merge on 'integration'.

            Without affecting the master, what is the branching model in which the current version of the plugin work?

            Show
            alfernie Al Ferguson added a comment - - edited Thanks Bue. There's something I don't understand, maybe related to the branching model. We develop our stories on separate feature branches, then we create pull requests to merge to our 'development' branch (The process to merge with the 'master' branch is not part of our development process, actually this merge comes later in our delivery process). When I installed the plugin, I did some tests on brand new branches: 'dev' and 'int'. It worked! The plugin did not attempt to make a new commit, it only applied existing 'dev' commits on 'int'. Since my tests were successful, I decided to delete my temporary branches and configure the plugin to build our existing 'development' branch and to merge within new 'integration' branch. Since that time we have the interesting situation described in this ticket. Why does the plugin try to perform an additional commit now it is configured on our real 'development' branch? Should the 'integration' branch be created in advance in the repository? If so, what must be the parent of the 'integration' branch? master: do not touch development: where developers' pull requests are merged story/**: features branches maintenance/**: guess integration: you tell me I want your plugin to build 'development' and, if successful, to merge on 'integration'. Without affecting the master, what is the branching model in which the current version of the plugin work?
            Hide
            bue Bue Petersen added a comment -

            The plugin is not build for serving pull request, as there are many pull request builders. You might be able to create a refspec to match pull request, and make it work though.

            Our git flow is designed so your just push your changes to a "ready" branch, and the plugin sees this and run the integration (if build steps succeeds).

            So let me suggest a simpler flow:

            master: do not touch (normally master is integration, but you can use another)
            story/**: your feature branches while developing on them, exist locally in developer clone or the corporate repo for backup
            integration: where you share work with you colleagues - it must be verified with pretested plugin first
            maintenance: ... you can have those also

            So when I'm done with my story/plugin-25872 I push it to a "ready" branch

            git push origin story/plugin-25872:ready/plugin-25872

            and my jenkins verify jobs start. If successful it merges ready/plugin-25872 into to "integration" branch. No need for pull requests.
            You can use Accummulated strategy, or the squashed strategy. Explained in details here: http://www.josra.org/blog/Pretested+integration+plugin.html

            If you would do this setup, you need:

            • one git repository configured in your job, explicitly name it 'origin'
            • git scm -> branch specifier: origin/ready/**
            • pretested integration plugin -> integration branch: integration
            • integration branch should already exist in the origin repo

            This way, whenever someone pushed to a ready-branch, the job starts and run your build steps and integrate changes if successful. Typically build steps like compile, compile unit-test, run unit-test are good criterias for sharing code.

            At some point later in your continuous delivery pipeline you will merge from integration branch to master, maybe after functional testing.

            The pretested integration plugin is made to automate our git flow: http://www.praqma.com/resources/papers/git-flow

            You still need to be able to run git command command line on your build slave, as the plugin does not work with other credentials in all cases.

            Show
            bue Bue Petersen added a comment - The plugin is not build for serving pull request, as there are many pull request builders. You might be able to create a refspec to match pull request, and make it work though. Our git flow is designed so your just push your changes to a "ready" branch, and the plugin sees this and run the integration (if build steps succeeds). So let me suggest a simpler flow: master: do not touch (normally master is integration, but you can use another) story/**: your feature branches while developing on them, exist locally in developer clone or the corporate repo for backup integration: where you share work with you colleagues - it must be verified with pretested plugin first maintenance: ... you can have those also So when I'm done with my story/plugin-25872 I push it to a "ready" branch git push origin story/plugin-25872:ready/plugin-25872 and my jenkins verify jobs start. If successful it merges ready/plugin-25872 into to "integration" branch. No need for pull requests. You can use Accummulated strategy, or the squashed strategy. Explained in details here: http://www.josra.org/blog/Pretested+integration+plugin.html If you would do this setup, you need: one git repository configured in your job, explicitly name it 'origin' git scm -> branch specifier: origin/ready/** pretested integration plugin -> integration branch: integration integration branch should already exist in the origin repo This way, whenever someone pushed to a ready-branch, the job starts and run your build steps and integrate changes if successful. Typically build steps like compile, compile unit-test, run unit-test are good criterias for sharing code. At some point later in your continuous delivery pipeline you will merge from integration branch to master, maybe after functional testing. The pretested integration plugin is made to automate our git flow: http://www.praqma.com/resources/papers/git-flow You still need to be able to run git command command line on your build slave, as the plugin does not work with other credentials in all cases.
            Hide
            lars_kruse Lars Kruse added a comment -

            This issue is transferred to GitHub Issues. Please follow https://github.com/Praqma/pretested-integration-plugin/issues/4

            Show
            lars_kruse Lars Kruse added a comment - This issue is transferred to GitHub Issues. Please follow https://github.com/Praqma/pretested-integration-plugin/issues/4

              People

              • Assignee:
                praqma Praqma Support
                Reporter:
                alfernie Al Ferguson
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: