Last modified: 2013-12-17 14:32:30 UTC
jenkins will sometimes claim that "This change was unable to be automatically merged with the current state of the repository." and vote V-1 when the change is mergeable. I've seen this happen a few times in the recent weeks, most recently on PS14 of https://gerrit.wikimedia.org/r/#/c/96810/ just now. The change shows "Can Merge: Yes", forcing a recheck or rebasing via gerrit results in V+1/2.
Looking at Zuul logs on gallium in /var/log/zuul/ the rebase failed when doing git remote update origin: GitCommandError: 'git remote update origin' returned exit status 1: hash mismatch^M key_verify failed for server_host_key^M fatal: The remote end hung up unexpectedly error: Could not fetch origin That happens from time to time, wondering whether that is an issue with Gerrit.
Created attachment 13910 [details] git exit status != 0 error in zuul.log Attached is: grep 'returned exit status' /var/log/zuul/zuul.log* The earliest log file is zuul.log.2013-10-27
Redirecting bug to git/gerrit. Git commands over ssh seems to yield hash mismatch from time to time, suspecting it comes from Gerrit. See attachment for a summary of the errors for the last 30 days or so. Note the issue happens on random repositories.
This has just happened to me locally, too, and worked when I retried. Maybe jenkins should just retry as well, as this is getting more and more annoying? F:\mediawiki\core\maintenance>git review -d 100378 Downloading refs/changes/78/100378/1 from gerrit Cannot fetch patchset contents Does specified change number belong to this project? The following command failed with exit code 128 "git fetch gerrit refs/changes/78/100378/1" ----------------------- hash mismatch key_verify failed for server_host_key fatal: The remote end hung up unexpectedly -----------------------
Marking as duplicate of an older bug report. *** This bug has been marked as a duplicate of bug 53895 ***