test-infra: PR tests triggered by a push occasionally fail with "not something we can merge"
This is on kubernetes/kubernetes#55794 For example https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/pr-logs/pull/55794/pull-kubernetes-bazel-build/16450/ fails with:
I1116 08:53:09.571] Call: git checkout -B test 6e950cc629981ad34e28cdc1a32834b930d6f679
W1116 08:53:09.896] Reset branch 'test'
I1116 08:53:09.899] process 34 exited with code 0 after 0.0m
I1116 08:53:09.900] Call: git merge --no-ff -m 'Merge +refs/pull/55794/head:refs/pr/55794' bd76307d9340ded350b3fb3fb616e1c095bba8be
W1116 08:53:09.918] merge: bd76307d9340ded350b3fb3fb616e1c095bba8be - not something we can merge
E1116 08:53:09.918] Command failed
I1116 08:53:09.919] process 55 exited with code 1 after 0.0m
When I do this on my side it works fine:
porridge@kielonek:~/projects/go/src/k8s.io/kubernetes$ git checkout -B test 6e950cc629981ad34e28cdc1a32834b930d6f679
Switched to a new branch 'test'
porridge@kielonek:~/projects/go/src/k8s.io/kubernetes$ git merge --no-ff -m 'Merge +refs/pull/55794/head:refs/pr/55794' bd76307d9340ded350b3fb3fb616e1c095bba8be
Merge made by the 'recursive' strategy.
cluster/gce/gci/master-helper.sh | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
porridge@kielonek:~/projects/go/src/k8s.io/kubernetes$
I suspect this earlier step is not fetching the correct commit?
I1116 08:53:04.779] Call: git fetch --quiet --tags https://github.com/kubernetes/kubernetes master +refs/pull/55794/head:refs/pr/55794
I1116 08:53:09.570] process 25 exited with code 0 after 0.1m
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 20 (17 by maintainers)
It might be reasonable to immediately retry once or twice or after a rather short delay? I agree that my immediate thinking is that jobs should generally fail and be re-run since usually we seem to just get bad refs / genuinely un-mergable code (not rebased yet), but we should perhaps take a look at options now that the old checkout scripts are hopefully on the way out.
Also, the far more common case is that tests were triggered but a force push has removed the commits. It’s impossible to tell which situation the clone fails from and retries in the common case are not going to be useful.
No, to be clear the behavior you saw was most likely GitHub API and GitHub git servers being inconsistent. The design is - the infrastructure determines the exact revision that is to be tested and failure to locate it is a failure to test it.