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" ?

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?

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.

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?

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.

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