-
Bug
-
Resolution: Not A Defect
-
Major
-
None
-
OS: Ubuntu 16.04, x86-64
Jenkins: 2.121.3 (Docker image)
github-branch-source: 2.3.6
github-api: 1.92
github: 1.29.2
cloudbees-folder: 6.5.1
After upgrading all the plugins on our Jenkins server (many months of updates), the periodic scan of our Github organisation is now behaving oddly: it doesn't pick up all our branches, and within each repository it seems to stop as soon as it hits a branch with a Jenkinsfile. For example:
Organization URL: SKA Africa [Thu Aug 23 11:39:17 UTC 2018] Consulting GitHub Organization 11:39:17 Connecting to https://api.github.com with no credentials, anonymous access <snip lots of ignoring> Examining ska-sa/spead2 Checking branches... Getting remote branches... Checking branch gcc_static_link_hack ‘Makefile.am’ not found Does not meet criteria Checking branch master ‘Makefile.am’ found Met criteria 2 branches were processed (query completed) 2 branches were processed Finished examining ska-sa/spead2
There are more branches of ska-sa/spead2 but they're not checked.
I've set up a brand new Jenkins install (from Docker) on my laptop to confirm this behaviour, so it's not just some gremlin left over from the upgrade.
Steps to reproduce:
- Start a fresh Jenkins from jenkins/jenkins:2.121.3 Docker image, run the wizard with default options.
- Add a Github organisation project. No credentials (we use creds in production, this is just for a test), organisation ska-sa, repository filter spead2, change the recogniser to Makefile.am (obviously that's not going to be valid Groovy, but it's just to demonstrate the issue since the organisation doesn't have a suitable public repository).
- Look for the above in the scan.
I haven't checked it on this toy Jenkins instance, but on our production Jenkins, scanning a single repository does pick up all the branches.
I tried poking through the code to try to figure out why that might be happening or which plugin is responsible, but I got lost in the web of inter-plugin calls so I've listed a few plugins that seemed like they might have some role. As far as I got was that this line seems to be where it bails out, which I think implies that SCMHeadObserver.isObserving returned false, but I'm not too sure what SCMHeadObserver subclass is in use at the time.