Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-37263

Jenkins checkout the wrong commit when used with the local branch behaviour on a branch with a / (slash)

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Labels:
    • Environment:
      Jenkins 2.16
      Windows Server 2012 R2
    • Similar Issues:

      Description

      Description of the problem

      I've a multibranch pipeline project configured with the local branch extension and many branch following the git flow model (features/xxxx). When I push a commit on the feature branch, this commit is detected by Jenkins, and pulled by the master to read the Jenkinsfile. The first time it works, but after that, the local branch is selected instead of the remote branch, amd the new commits are not fetch. The bug only occurs on branches with a slash in their names.

      Investigation

      I've connected my debugger to my Jenkins installation.

      It appears that Jenkins has detected 2 branches matching the name. One local and one remote. The local one is created by the local branch git extension.

      I can't explicitly specify to Jenkins to use the remote one because I use the pipeline plugin, and this checkout is made automatically to retrieve the Jenkinsfile. So, the git implementation takes the first one, which is generally the local branch which is not yet updated...

      Revision marked = candidates.iterator().next();
      

      Logs

      16:10:31 Multiple candidate revisions
      16:10:31 Checking out Revision 604398f062b459c797f31d6c13b568dd7612362d (features/my-feature-branch)
      16:10:31  > git.exe config core.sparsecheckout # timeout=30
      16:10:31  > git.exe checkout -f 604398f062b459c797f31d6c13b568dd7612362d # timeout=120
      16:10:32  > git.exe branch -a -v --no-abbrev # timeout=30
      16:10:32  > git.exe branch -D features/my-feature-branch # timeout=30
      16:10:32  > git.exe checkout -b features/my-feature-branch 604398f062b459c797f31d6c13b568dd7612362d # timeout=120
      16:10:32  > git.exe rev-list 0fa6b0371aa1e77a35acdc9f82bb68bb2c32fb2d # timeout=30
      

      How to fix it

      Possibilities I see :

      • Update the workflow-multibranch-plugin / branch-api-plugin to checkout on origin (prefix with refs/remotes/origin/)
      • Update the git-plugin to order the list, and prioritize remote branches

      Personally, I think the first one is safer, but I've not yet played with this plugin.

      Here is my proposition on Github: https://github.com/jenkinsci/branch-api-plugin/pull/47

      How to reproduce

      1. Create a new repository and initialize it (on github, with a README.md for example)
      2. Clone it on your computer:
        git clone https://lausivoiduts.visualstudio.com/QuarahMC/_git/JENKINS-37263
        cd JENKINS-37263
        
      3. Create a new branch:
        git checkout -b features/this-bug
        
      4. Add something in the Jenkinsfile:
        echo "echo 'first commit' " > Jenkinsfile
        
      5. Commit and push it:
        git add Jenkinfile
        git commit -m "first commit" 
        git push --set-upstream origin features/this-bug
        
      6. Add a new Multibranch Pipeline Project in Jenkins, add as Source your git repository.
        Click on "Add Behaviour", select "Checkout to a local branch".
        Set its value to "**" (without the quotes).
        Validate it.
      7. Check that the branch was built, and the message "first commit" appears in the log
      8. Modify your Jenkinsfile:
        echo "echo 'second commit' " > Jenkinsfile
        
      9. Commit and push it:
        git add Jenkinfile
        git commit -m "second commit"
        git push
        
      10. Run the branch indexing
      11. Check that the branch is built. Check the log, you'll see "first commit" instead of "second commit".

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment -

            Quentin Dufour thanks very much for investigating. I won't be able to do any further checks until after 16 Sep 2016. I think I saw the problem at least once with my docker instance and its verification jobs, but will need further investigation to confirm the conditions.

            Show
            markewaite Mark Waite added a comment - Quentin Dufour thanks very much for investigating. I won't be able to do any further checks until after 16 Sep 2016. I think I saw the problem at least once with my docker instance and its verification jobs, but will need further investigation to confirm the conditions.
            Hide
            mempf Josh Ancill added a comment -

            This is still a problem with Jenkins 2.25 with up to date plugins as of October 24th 2016. Using the git branch naming scheme: feature/new-feature fairly reliably causes the issue to occur more often than not.

            Show
            mempf Josh Ancill added a comment - This is still a problem with Jenkins 2.25 with up to date plugins as of October 24th 2016. Using the git branch naming scheme: feature/new-feature fairly reliably causes the issue to occur more often than not.
            Hide
            avdbom Anne van der Bom added a comment -

            Just a confirmation that the error still persists in version 2.32.3. 

            Show
            avdbom Anne van der Bom added a comment - Just a confirmation that the error still persists in version 2.32.3. 
            Hide
            autarch Dave Rolsky added a comment -

            We're having the same problem on our Jenkins system too. We have the same configuration of checking out to a local branch. The logs show the same "Multiple candidate revisions" message, and then it picks the revision that's currently checked out.

            This doesn't happen with every branch. I assume this is because the order of the revisions is either random or determined by some sort of ordering that can put either the remote or local first, depending on something like the branch name. So sometimes it picks the remote branch and sometimes it picks the local.

            Show
            autarch Dave Rolsky added a comment - We're having the same problem on our Jenkins system too. We have the same configuration of checking out to a local branch. The logs show the same "Multiple candidate revisions" message, and then it picks the revision that's currently checked out. This doesn't happen with  every branch. I assume this is because the order of the revisions is either random or determined by some sort of ordering that can put either the remote or local first, depending on something like the branch name. So sometimes it picks the remote branch and sometimes it picks the local.
            Hide
            jimmyjudas James Housley added a comment - - edited

            I was having this issue when using "origin" as the "Name" of my git repository in the job's settings, and then using e.g. "abc/def" as my branch specifier. Removing the Name and instead using "origin/abc/def" as my branch specifier fixed the issue.

            Show
            jimmyjudas James Housley added a comment - - edited I was having this issue when using "origin" as the "Name" of my git repository in the job's settings, and then using e.g. "abc/def" as my branch specifier. Removing the Name and instead using "origin/abc/def" as my branch specifier fixed the issue.

              People

              • Assignee:
                Unassigned
                Reporter:
                superboum Quentin Dufour
              • Votes:
                6 Vote for this issue
                Watchers:
                12 Start watching this issue

                Dates

                • Created:
                  Updated: