| matmarex | |
| Nov 23 2013, 4:52 PM |
| F12734: file_57483.txt | |
| Nov 22 2014, 2:40 AM |
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.
Version: unspecified
Severity: major
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
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
Attached:
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
Marking as duplicate of an older bug report.