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

Pushing a fast-forward merge does not trigger a build

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: git-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      I have a single job configured to build all branches of a git repo and poll for changes, and I have been experiencing a bug with build triggering.

      Steps to reproduce

      1. Create a new repo locally and run these in the repo:
        touch somefile.txt
        git commit -m "Add a file" somefile.txt
        
      2. Create a new repo on github
      3. Create a Jenkins job with this configuration:
        • Set 'Repository URL' to the new github repo
        • Set 'Branches to build' to '**'
        • Check 'Prune remote branches before build', 'Skip internal tag', 'Clean after checkout', 'Recursively update submodules', 'Wipe out workspace before build'
        • Check 'Poll SCM'
        • Set 'Schedule' to '* * * * *'
        • Add the following shell script as a build step:
          echo $GIT_BRANCH
      4. Push the master branch of your local repo to github
      5. Wait for Jenkins build (build #1)
      6. Run these in your local repo:
        git checkout -b feature master
        echo stuff > somefile.txt
        git commit -m "Some changes" somefile.txt
        git push origin feature
        
      7. Wait for Jenkins build (build #2)
      8. Run these in your local repo:
        git checkout master
        git merge feature
        git push origin master
        

      What happens

      After step 5, build #1 prints 'origin/master'. After step 7, build #2 prints 'origin/feature'. After step 8, nothing happens in Jenkins.

      What should happen

      Builds #1 and #2 are fine. There should be a build #3 after step 8 which prints 'origin/master'.

        Attachments

          Activity

          Hide
          dant3 Vyacheslav Blinov added a comment -

          Same here. Our environment uses automated deployment based on branching. As we merge changes to master we expect Jenkins to build them in master providing new artefact independently of is this the same SHA as in other branch, that Jenkins builded earlier. There is no way to choose such strategy atm.

          Show
          dant3 Vyacheslav Blinov added a comment - Same here. Our environment uses automated deployment based on branching. As we merge changes to master we expect Jenkins to build them in master providing new artefact independently of is this the same SHA as in other branch, that Jenkins builded earlier. There is no way to choose such strategy atm.
          Hide
          ndeloof Nicolas De Loof added a comment -

          There is no actual distinction between "feature" and the fast-forwarded merge on "master". This is what merge-commit are designed for, if your workflow explicitly expect to track such merges

          Show
          ndeloof Nicolas De Loof added a comment - There is no actual distinction between "feature" and the fast-forwarded merge on "master". This is what merge-commit are designed for, if your workflow explicitly expect to track such merges

            People

            • Assignee:
              ndeloof Nicolas De Loof
              Reporter:
              nriffe nriffe
            • Votes:
              4 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: