feat: Respect user-defined Git author identity in merges

[KrasimirAntonov]

Description

Previously, MergeWithGitSCMExtension always used hardcoded values "Jenkins" / "nobody@nowhere" as the author and committer of the merge commit, ignoring any user-configured identity.

The decorateRevisionToBuild method now resolves the identity in the following order:

1. If a UserIdentity extension is configured in the GitSCM, it is applied via userIdentity.decorate(scm, git).
2. Otherwise, it falls back to the global descriptor configuration (getGlobalConfigName() / getGlobalConfigEmail()), and only uses "Jenkins" / "nobody@nowhere" when those values are null.

Testing done

Three automated tests were added to MergeWithGitSCMExtensionTest:

• testMergeCommitUsesDefaultIdentity — verifies that when no identity is configured, the merge commit is authored by Jenkins / nobody@nowhere.
• testMergeCommitUsesGlobalConfigIdentity — sets globalConfigName / globalConfigEmail on the GitSCM descriptor and verifies the merge commit reflects those values.
• testMergeCommitUsesUserIdentityExtension — adds a UserIdentity extension to the SCM and verifies it takes precedence over the global config.

All three tests build a real Jenkins freestyle project with a diverging branch scenario and inspect the HEAD commit's PersonIdent via JGit's RevWalk.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests

[MarkEWaite]

I'm not willing to accept this change into the plugin because I believe that merges should be performed in Pipeline scripts using command line git rather than relying on an freestyle jobs and an implementation inside the plugin.

[MarkEWaite]

Closing the pull request because I'm unwilling to accept changes in this area.

[KrasimirAntonov]

Hi @MarkEWaite

Just to clarify: what is the intended functionality of specifying user.name and user.email if they have no effect later in the pipeline execution? I’m trying to better understand the purpose of exposing these settings.

Thanks.

[MarkEWaite]

what is the intended functionality of specifying user.name and user.email if they have no effect later in the pipeline execution? I’m trying to better understand the purpose of exposing these settings.

The custom user name / e-mail address is in the same condition as the merge extension. I don't plan to add anything to that area of the plugin. I won't remove it, because that would break some users, but I don't plan to modify it in the future.