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

SCM polling does not find new branch

    XMLWordPrintable

Details

    Description

      Defining branch "origin/test/*" build does not start with SCM poll. If the build is started by hand it is working, then it finds the change.

      Attachments

        Issue Links

          Activity

            I'm hitting the same issue on a freestyle multibranch GitHub project. I think it's linked to https://issues.jenkins-ci.org/browse/JENKINS-41234

            • The GitHub webhook works and is received correctly by Jenkins
            • Builds will not start automatically when new commits are pushed to an existing branch
            • Starting a "Scan Project" run manually will poll GitHub, notice the changes, and trigger builds for all updated branches since the last run.

            Versions:

            • Jenkins 2.43
            • Branch API plugin 2.0.2-beta-5
            • SCM API plugin 2.0.2-beta-2
            • GitHub API plugin 1.84
            • GitHub Branch Source plugin 2.0.1-beta-6

            For me, this problem coincides with the SCM API 2.0 upgrade. For this reason, I think this bug might belong in the JENKINS-41234 epic

            gcsventures Guillaume Ceccarelli added a comment - I'm hitting the same issue on a freestyle multibranch GitHub project. I think it's linked to https://issues.jenkins-ci.org/browse/JENKINS-41234 The GitHub webhook works and is received correctly by Jenkins Builds will not start automatically when new commits are pushed to an existing branch Starting a "Scan Project" run manually will poll GitHub, notice the changes, and trigger builds for all updated branches since the last run. Versions: Jenkins 2.43 Branch API plugin 2.0.2-beta-5 SCM API plugin 2.0.2-beta-2 GitHub API plugin 1.84 GitHub Branch Source plugin 2.0.1-beta-6 For me, this problem coincides with the SCM API 2.0 upgrade. For this reason, I think this bug might belong in the JENKINS-41234 epic

            Reverting to Branch API 1.11.1 + SCM API 2.0.1 + Github Branch Source 1.10.1 fixes this for me.

            gcsventures Guillaume Ceccarelli added a comment - Reverting to Branch API 1.11.1 + SCM API 2.0.1 + Github Branch Source 1.10.1 fixes this for me.

            That plugin has not been released yet: https://wiki.jenkins-ci.org/display/JENKINS/Freestyle+Multibranch+Plugin or is it a different plugin you are referring to?

            stephenconnolly Stephen Connolly added a comment - That plugin has not been released yet: https://wiki.jenkins-ci.org/display/JENKINS/Freestyle+Multibranch+Plugin or is it a different plugin you are referring to?
            gcsventures Guillaume Ceccarelli added a comment - stephenconnolly I was referring to https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin

            gcsventures So looking at that project type, there are a lot of hacks and some incorrect assumptions on how Branch API is supposed to work. I suspect the plugin maintainer would need to figure out how to correct their usage of Branch API now that the correct usage is documented.

            That is assuming the plugin maintainer is still interested in that plugin, given that the wiki page directs towards pipeline I am unsure.

            Certainly the code looks to have a lot of hacks enough that I cannot see what it is doing wrong, particularly scary from my PoV is that it doesn't seem to want to ensure that the branch details are stored with each branch job (storing in a property being fragile they way it has been implemented in the plugin, probably better to store in a side-file so that the UI config cannot remove)

            There also seem to be some incorrect assumptions about source ids and other things.

            stephenconnolly Stephen Connolly added a comment - gcsventures So looking at that project type, there are a lot of hacks and some incorrect assumptions on how Branch API is supposed to work. I suspect the plugin maintainer would need to figure out how to correct their usage of Branch API now that the correct usage is documented. That is assuming the plugin maintainer is still interested in that plugin, given that the wiki page directs towards pipeline I am unsure. Certainly the code looks to have a lot of hacks enough that I cannot see what it is doing wrong, particularly scary from my PoV is that it doesn't seem to want to ensure that the branch details are stored with each branch job (storing in a property being fragile they way it has been implemented in the plugin, probably better to store in a side-file so that the UI config cannot remove) There also seem to be some incorrect assumptions about source ids and other things.

            https://github.com/jenkinsci/multi-branch-project-plugin/pull/145 is probably sufficient to limp this plugin along

            stephenconnolly Stephen Connolly added a comment - https://github.com/jenkinsci/multi-branch-project-plugin/pull/145 is probably sufficient to limp this plugin along

            Specifically this test should be confirming that this issue has been resolved

            stephenconnolly Stephen Connolly added a comment - Specifically this test should be confirming that this issue has been resolved

            Fixed in version 0.6

            mjdetullio Matthew DeTullio added a comment - Fixed in version 0.6

            People

              mjdetullio Matthew DeTullio
              gaalandr Andras Gaal
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: