The gist of this is that due to some encoding change made in the SCM API 2.0 release, conventional URIs

This was originally noticed by the Blue Ocean team in this pull request discussing integrating SCM API 2.0 changes. See also JENKINS-40299.

The blog post discusses some of the data migrations which are supposed to take place, however the URI changing issue results in two bad behaviors:

* URIs change for Multibranch-based Pipelines which use "special characters" in their names, such as improvement/JENKINS-41047 would previously be located at: https://ci.blueocean.io/job/blueocean/job/improvement%2FJENKINS-41047/. After these changes it would be found at https://ci.blueocean.io/job/blueocean/job/improvement-JENKINS-41047.d61e72/
* Post-upgrade, rebooting the Jenkins installation results in *every* Multibranch Pipeline being retriggered. Such as this Pipeline despite no new changes being made.


Because the upgrade to SCM API 2.0 is a one-direction-only change, I propose we blacklist the updated versions of the plugins referenced in this post before too many people upgrade a non-reversible upgrade.

Incorrect analysis with lots of FUD.

The renaming of jobs has nothing to do here.

The issue here is that GitHub Branch Source 1.x passes a null id to the constructor of it's SCMSource: https://github.com/jenkinsci/github-branch-source-plugin/blob/1.10-stable/src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMNavigator.java#L312

This means that every time you perform a scan of the organization folder, all the SCMSource instances get a new ID.

When the branch changes SCMSource instance (i.e. the ID is different) then the Branch API is supposed to trigger a rebuild (because the branch is from a different source, never mind that it may be the same revision, we have no way of knowing)

In 2.x we have a consistent ID: https://github.com/jenkinsci/github-branch-source-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMNavigator.java#L446

The issue here is that GitHub Branch Source did not correctly ensure that the SCMSource from a Organization Folder had a consistent ID.

Thus, every time you do a scan of an organization folder, with the old logic it should have been re-triggering a build... It wasn't because of other bugs... this leads to things like "I cannot re-trigger PRs", etc

In fixing the problems in GitHub Branch Source, we get to a point where everything is behaving correctly, but the data for the previous branch origins is not current and thus the PRs have not been built from their current source.