Dealing with post-build push failure

When a validated merge build succeeds, Jenkins will push the merge commit to the upstream repository, but if someone else has pushed new commits to the same branch while Jenkins was validating the submitted changes, this push will fail. The Git jargon for this is that the push is not a fast-forward. Causing a build to fail because of this is not necessarily desirable, because there actually wasn’t any problem in the submitted changes. In the "advanced" section of the "Enable Git validated merge support" feature in the job configuration screen, you can tell Jenkins how to deal with this situation.

Merge and push
Given that the submitted changes were OK, Jenkins will perform another merge between the commit that was just validated and the commit that’s currently in the upstream repository, then push the new merge commit to the upstream. If a merge fails, the build will be marked as a failure. This is basically assuming that there are no undesirable interaction between the changes that were submitted to Jenkins and the changes that were pushed to the upstream repository. This requires less computing cycles, but it has a potential risk of broken builds in the branch tip. This is generally a desirable option if your validated merge takes a significant amount of time.
Redo a validated merge
Start a new validated merge all over again, with the newly discovered commit in the upstream repository. The current build gets marked as aborted, then a new one will be started with the same submitted changes. This requires additional computing cycles, but it will guarantee that no untested commits ever land on the upstream repository. This is generally a desirable option if your validated merge completes quickly.
Fail the build if push fails
Cause a build to fail. This is essentially asking the submitter of the changes to deal with the situation. He can then choose to resubmit the changes, or push straight into the upstream. This is a desirable option if none of the other options suit your needs.

This behaviour is extensible. Other plugins can implement custom behaviours.