soar We had a similar issue and we were able to workaround the specific issue by deleting the contents of:

/var/lib/jenkins/org.jenkinsci.plugins.github_branch_source.GitHubSCMProbe.cache 

On our Jenkins server. We have not yet identified the underlying cause however.

Looks like working branch rebasing causes this issue

I am also experiencing this issue.

Same issue here.  This is starting to happen more frequently and is becoming a nuisance.

As scotje suggested, clearing the contents of $jenkins_home/org.jenkinsci.plugins.github_branch_source.GitHubSCMProbe.cache and triggering a rescan of the repository temporarily resolved the issue.

Same issue. Causing a lot of developer frustration on the team.

@soar It seems rebasing the working branch is causing the issue for us too.

The problem is very urgent and serious obstacle to our work. Every hour I have to clear the cache. Forced to do a job for this even

Maybe it makes sense to raise the priority to the blocker or critical?

I wonder if it has anything to do with the cache just being recently turned on again by default here:

https://github.com/jenkinsci/github-branch-source-plugin/commit/1b3a370d78a4f8b431a55bc79ee795f1d8cece88

The time when people started reporting this issue and when that changed happened in early October seem to line up.

https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin

The cache can be disabled by setting -Dorg.jenkinsci.plugins.github_branch_source.GitHubSCMSource.cacheSize=0. My guess is that will serve as a decent work around seeing as the cache wasn't on prior and shouldn't have any adverse affects AFAIK.

awiddersheim  I have tried setting the JVM property but that does'nt  create the new job config for each branch source. Hence, the Jenkinsfile changes are ignored though a scan on repository picks the change in commit SHA Is there any alternative?

Branch source plugin is creating a stale job directory with the current builds folder job source. Appears like the fingerprints help to keep duplictaes on jenkins.

I can confirm that -Dorg.jenkinsci.plugins.github_branch_source.GitHubSCMSource.cacheSize=0 doesn't help. Only cronjob which removes cache directory every one minute did the trick.

Has been observed recently on ci.jenkins.io as well.

If you turn off the cache and clear the cache dir does the problem come back?

Removing Stephen as the owner. vivek, FYI. I believe you are already aware.

stephenconnolly rsandell As reported above disabling cache (using -Dorg.jenkinsci.plugins.github_branch_source.GitHubSCMSource.cacheSize=0) doesn't help, removing the caching directory does. Perhaps, if caching is disabled, we should cleanup the caches as well in fail safe manner?

I am guessing, might be the case of cache is not getting correctly invalidated resulting in such behavior.

As a workaround, is it safe to nuke $jenkins_home/org.jenkinsci.plugins.github_branch_source.GitHubSCMProbe.cache while jenkins is running as a workaround? Would this potentially cause us to miss any events?

npwolf On running Jenkins, it might. Well, you have to disable the cache anyways, that needs setting this jvm property -Dorg.jenkinsci.plugins.github_branch_source.GitHubSCMSource.cacheSize=0.

We have hit this issue several times recently, and we'd really like to get something in place to mitigate it ASAP, even if it's a temporary measure. I would appreciate it very much if anyone here could clarify any of the following points:

• When will rsandell's fix be available? (It looks like the newest currently-available version of the branch source plugin, 2.4.3-beta-1, was built on January 28th, while that PR was merged in late February)
• soar seems happy with a cron job that blows away the cache every minute, while vivek suggests that nuking the cache while Jenkins is running could cause issues. What kinds of issues might be caused by disabling the cache in a running system?
• Several people seem to have concluded that setting the cacheSize=0 JVM property does not help, but in the most recent comment in this thread, Vivek says that, "you have to disable the cache anyways, that needs setting this jvm property". Has anyone actually been able to mitigate this issue by setting that property?

Thanks!

Yes, adding the JVM argument to disable the cache did the job for me.

Here are the steps we are using to reproduce the issue: 

• create a branch
• commit something
• create a PR
• merge the PR with master 
• delete the branch on Github enterprise ui. 

• create a branch with the same name from master, (the branch name is the same as the previous one, but that's ok since we deleted already from the github ui). 
• now if we create another PR using this branch, even it shows up properly on the github UI, a scan in Jenkins shows no Jenkinsfile found thus the new PR could not be built.

any update on a fix? we're having the same issue.

Suffering from the same issue here.
Jenkins core 2.164.1
GitHub branch source 2.5

We use a pipeline script to clear the cache whenever there is an issue.

node('master'){
    stage('Clear cache'){
        sh "rm -r $jenkins_home/org.jenkinsci.plugins.github_branch_source.GitHubSCMProbe.cache"
    }
}

It's not ideal, but hopefully someone else finds it useful.

This breaks the plugin for anyone doing PRs. Really shouldn't be any further releases until this is fixed. 

We have rolled back for now and are opting out of upgrades.

dbsanfte
What did you roll back to that "fixed" this issue for you? Could you provide same additional details about your configuration and what output you're seeing?

dbsanfte amirbarkal
There is a new version v2.5.1 the fixes PRs from forks.

synalogik, amirbarkal, dbsanfte, soar
If anyone is interested in trying it, I have an experimental version of the github-branch-source-plugin using okttp3.
Removed
If you have a test/staging Jenkins on which your are comfortable trying this out it would be helpful to know if this issue would be fixed by this upgrade.

The code can be seen at https://github.com/jenkinsci/github-branch-source-plugin/pull/223

bitwiseman maybe we can run this at least temporarily on ci.jenkins.io? I know rtyler has a strict “no experimental code” rule for this server, but the current situation is badly broken to begin with.

jsoref
In what context is this?

 I don't understand your question. We use the organization plug-in discover repositories and branches. This beta plug-in broke all of our builds immediately.

I observed behavior that Jenkins will ignore PR if  that PR has conflicting files.

jsoref, synalogik, amirbarkal, dbsanfte, soar
Here's the updated plugin with okio (thanks Josh!).
Removed

armantur
Could you open a new issue for that, it is probably not related to this issue.

Liam Newman: I don't think it helped

jsoref
Updated again. I manually tested it this time on my local jenkins. Builds run.
https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/github-branch-source/2.5.3-rc841.52a0b90bff37/

bitwiseman: that one works!

I'll leave it running. And if anything explodes, I'll let you know. Otherwise, I look forward to finally upgrading to a working plugin.

Thanks

jsoref
Okay, so to be clear this is still an experiment/exploration. The point of this exploration is to see if switching to using okhttp3 will address the FileNotFound issues. We're going to need more reports before we can release it.

synalogik, amirbarkal, dbsanfte, soar (and anyone else)
Please give this version of the plug a try: https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/github-branch-source/2.5.3-rc841.52a0b90bff37/

bitwiseman
Not really sure how to reproduce this - can you post instructions?
We’re using Multibranch pipeline repository with GitHub branch source configured to build PRs, branches and tags.

So, we aren't currently hitting the

‘Jenkinsfile’ not found

problem, but we are seeing that the periodic scans don't seem to be running periodically, and a branch whose name has been recycled (but for whom we'd expect github to send a notification) isn't being noticed automatically.

We are able to use "Scan Repository Now" to pick up those branches, which feels like progress.

jsoref
Let's talk about an issues you see with okhttp3 version as a separate issue:
https://issues.jenkins-ci.org/browse/JENKINS-57411

We sort of hijacked this issue as something that might be fixed by the okhttp3 upgrade. If you see this issue again, it should go here, if you see other issues that should go there. Sound good?

soar, scotje, jcollard, jsoref, dbsanfte, aedwards, synalogik, npwolf
We're are trying to test whether this underlying issue could be fixed or improved by moving to okhttp3. If you are willing to help, please try the patched version of the plugin shown in the description of https://issues.jenkins-ci.org/browse/JENKINS-57411 . Thanks.

I tried 2.5.4-rc849.b58a1bae7fce, it did not fix the issue for me.

I had been running builds on the branch (without a PR up) with no problem. Then as soon as I made a PR for the branch, Jenkins lost track of the branch and PR because it could no longer see the Jenkinsfile on scan. I had made the PR after merging master, and resolving conflicts in the Jenkinsfile.

Deleting the cache (as above), also fixed this for me.

Workaround that worked for me:

Groovy config - for a container

org.jenkinsci.plugins.github_branch_source.GitHubSCMSource.cacheSize=0

And

GitHubServerConfig server = new GitHubServerConfig("my_github_credential_API"); 
server.setApiUrl(githubAPIurl)
server.setClientCacheSize(0) //<--See https://issues.jenkins-ci.org/browse/JENKINS-54126. Had to disable this one too to get this to stop happening

Once both of those are configured, delete the directory:

$jenkins_home/org.jenkinsci.plugins.github_branch_source.GitHubSCMProbe.cache

Now that directory is not getting re-populated.  Not sure why 2nd code block was required, but for what its worth, to the next person.

Hello All - 

I had this same issue with the Jenkinsfile was being discovered during the scan.  After deleting the cache file specified and re-scanning it worked perfectly.

thomasliddledba
It is good to know the workaround still works. Thanks!

This issue occurred on one our branch today. On login to Jenkins server I noticed entire branch was missing under jobs folder. We use Multipipeline project and 2.164.2, this is so annoying as we lost entire history of PR(s) that went to this branch. We map build number to PR to do feature testing and now we don't have that details. 

We encountered this problem today, we have:
Jenkins v2.176.2
Branch API Plugin v2.5.4
GitHub Branch Source v2.5.5
Multijob plugin v 1.32
Pipeline: Multibranch 2.21

deleting the files under $JENKINS_HOME/org.jenkinsci.plugins.github_branch_source.GitHubSCMProbe.cache resolved the problem. This isn't a viable longterm solution though.

Steps to reproduce:
1. Create a branch testbranch that is one commit behind the tip of master (or some branch that is to be merged into)
2. Make a commit to testbranch that will cause a conflict with the latest on master.
3. In GitHub, create a pull-request for testbranch to be merged into master. (It will warn you that it can't be automatically merged, but "don't worry, you can still create the pull-request". (Jenkins Multibranch pipeline will refuse to create a build for both the branch and the PR).
4. Rebase testbranch off the latest on master, resolve the conflicts, and git push origin testbranch --force.
5. Jenkins Multibranch pipeline will catch that the branch changed, and build the branch, however, it still doesn't sense the pull-request, and refuses to create a build for it.

Closing and re-opening the pull-request doesn't help.
Closing the pull-request and opening a new one (for the same, conflict-free branch) does work (but is obviously not ideal).
rm -rf $JENKINS_HOME/org.jenkinsci.plugins.github_branch_source.GitHubSCMProbe.cache/* does work.

I'd also like to state that there indeed was a Jenkinsfile on testbranch, and that the trigger of this bug is when there's a merge conflict at the time the pull-request is created.

Jenkins 2.176.2
GitHub Source Plugin 2.5.6
Pipeline: Multibranch 2.21

We're seeing this all the time on PRs that use the draft PR feature in GitHub. I found a related issue reported for it already:

https://issues.jenkins-ci.org/browse/JENKINS-57206

Seeing this happen still,

Jenkins 2.190.1
Github Branch Source Plugin. 2.5.8
Pipeline: Multibranch: 2.21

This has been happening from time to time for us and now again today.

I did notice in a related/linked issue, https://issues.jenkins-ci.org/browse/JENKINS-57206, that this might be related to the webhook from github setting:
"mergeable_state": "unknown",
And I can confirm that it is what was sent in our case. And to recover we had to delete the cache at `$JENKINS_HOME/org.jenkinsci.plugins.github_branch_source.GitHubSCMProbe.cache/*` as it would not recover by re-scanning nor retriggering the webhook.