This is a Freestyle job. In reviewing the builds, I found at least one other time that it happened.
Build# GIT SHA1 Commit Date Commit Time(Local)
410 2b58345046bb484219462801509be5cd3d76add3 2018-11-07 17:08:08
409 1595cf0d1376d1d5130579ae4b365326fe3f0ad1 2018-11-09 10:53:07
384 c28d07d4faf56dd59d4f0f7d5ca205ca786ba4ea 2018-10-24 13:40:54
383 37dc2da724de54b37639365b765940a7bf02f89e 2018-10-24 14:15:39
In reviewing the log files to answer your questions, I found this:
11:50:16 > git rev-parse "release/6.4^{commit}" # timeout=10*11:50:16* > git rev-parse "refs/remotes/origin/release/6.4^{commit}" # timeout=10*11:50:16* Multiple candidate revisions*11:50:16* Scheduling another build to catch up with C2E_6.4_CI
When I did a search on "Multiple candidate revisions", I found this on Stackoverflow:
https://stackoverflow.com/questions/49864570/jenkins-pipeline-having-multiple-candidate-revisions-and-is-picking-old-one
Is it possible that because I have the branch specifier as "release/6.4", that it's creating a local branch and getting confused between the local branch and the remote branch? Should I change the branch specifier to "remotes/origin/release/6.4"?
Can you provide any further details on the conditions when the problem happened?
Specifically, can you provide a numbered series of steps which will allow someone else to repeat the problem?
If not, can you provide the job definition which shows the problem? Specifically, is it a Freestyle job or a Pipeline job or a multibranch Pipeline job? Does the job definition use any other git plugin extensions like "checkout to a subdirectory" or "Require a workspace"?