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

SCM polling does not find new branch

XMLWordPrintable

      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.

          [JENKINS-41371] SCM polling does not find new branch

          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

          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

          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.

          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.

          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?

          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?

          Guillaume Ceccarelli added a comment -

          stephenconnolly I was referring to https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin

          Guillaume Ceccarelli added a comment - stephenconnolly I was referring to https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin

          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.

          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.

          Stephen Connolly added a comment -

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

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

          Stephen Connolly added a comment -

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

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

          Matthew DeTullio added a comment -

          Fixed in version 0.6

          Matthew DeTullio added a comment - Fixed in version 0.6

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

              Created:
              Updated:
              Resolved: