• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None
    • Freestyle project
      Jenkins 2.134
      Windows 10
      Plugins are listed in the attached build log.

      The builds on our release branch, release/6.4, do not always pick up the latest commit.  It was 15 commits behind the most recent commit on the most recent build, which is build 410.  Build 409, however, used the correct commit.   JENKINS-37263 describes a similar problem, but the issue occurred on a local branch and this is not a local branch.

      The build logs are attached and any company or user specific info has been changed to be generic.

          [JENKINS-54895] Jenkins build used wrong commit number

          Mark Waite added a comment -

          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"?

          Mark Waite added a comment - 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"?

          Janet Dermer added a comment -

          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"?

          Janet Dermer added a comment - 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"?

          Mark Waite added a comment -

          I think you'll get better results with that more precise branch name (or with the name origin/release/6.4

          Mark Waite added a comment - I think you'll get better results with that more precise branch name (or with the name origin/release/6.4

            Unassigned Unassigned
            altatude1 Janet Dermer
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: