SCM API 2.0 Release Take 2

Upgrading should make multi-branch projects much better. When you are ready to upgrade you must ensure that you upgrade all the required plugins. If you miss some, just upgrade them and restart to fix the issue. And of course, it’s always a good idea to take a backup of your JENKINS_HOME before upgrading any plugins.

In the list below, version numbers in bold indicate a change from the original version in the original announcement

If you are using the Blue Ocean plugin

Other plugins that may require updating:

After an upgrade you will see the data migration warning (see the screenshot in JENKINS-41608 for an example) this is normal and expected. The unreadable data will be removed by the next scan / index or can be removed manually using the Discard Unreadable Data button. The warning will disappear on the next restart after the unreadable data has been removed.

Please update to the versions listed above. If you want to know more about the issues and how they were resolved, see the next section.

The issues described below are resolved with these plugin releases:

JENKINS-41121: GitHub Branch Source upgrade can cause a lot of rebuilds:

Migration of GitHub branches from 1.x to 2.x resulted in a change of the implementation class used to identify branches. Some other other bugs in Branch API had been fixed and the combined effect resulted in a rebuild of all GitHub Branches (not PRs) after an upgrade to GitHub Branch Source Plugin 2.0.0. This rebuild was referred to as a "build storm".

Resolution:

JENKINS-41255: Upgrading from a navigator that did not assign consistent source ids to a version that does assign consistent source ids causes a build storm on first scan:

The GitHub Branch Source and BitBucket Branch Source plugins in 1.x were not assigning consistent IDs to multi-branch projects discovered in an Organization Folder. Both plugins were fixed in 2.0.0 to assign consistent IDs as a change of ID would result in a rebuild of all projects. What was missed is that the very first scan of an Organization Folder after an upgrade will change the randomly assigned ID assigned by the 1.x plugins into the consistent ID assigned by the 2.0.0 plugins and consequently trigger a rebuild of all branches. This rebuild was referred to as a "build storm".

Resolution:

The Branch API plugin was enhanced to detect the case where a branch source has been changed but the change is only changing the ID. When such changes are identified, the downstream references of the ID are all updated which will prevent a build storm.

JENKINS-41313: On first index after upgrade to 2.0.0 all open PRs are rebuilt:

The BitBucket Branch Source 1.x did not store all the information about PRs that is required by the SCM API 2.0.x model. This could well have resulted in subtle effects when manually triggering a rebuild of a merge PR if the PR’s target branch has been modified after the PR branch was first detected by Jenkins. Consequently, as the information is required, BitBucket Branch Source plugin 2.0.0 populated the information with dummy values which would force the correct information to be retrieved. The side-effect is that all PR branches would be rebuilt.

Resolution:

JENKINS-41124: Can’t get a human readable job name anymore:

During initial testing of the Branch API 2.0.0 release an issue was identified with how Organization Folders handled unusual names. None of the existing implementations of the SCMNavigator API could generate such unusual names due to form validation on GitHub / BitBucket replacing unusual characters with - when creating a repository.

It would be irresponsible to rely on external services sanitizing their input data for the correct operation of Organization Folders. Consequently, in Branch API 2.0.0 the names were all transformed into URL safe names, with the original URLs still resolving to the original projects so that any existing saved links would remain functional.

Quite a number of people objected to this change of URL scheme.

Resolution:

Side-effect:

This means that the Jenkins Item rename API cannot be used.

At this time, the only known side-effect is in the Job Configuration History plugin. The configuration history of each child item will still be tracked going forward after the upgrade. The pre-upgrade configuration history is also retained. Because the Jenkins Item rename API cannot be used to flag the configuration file location change, there is no association between the pre-upgrade history chain and the post-upgrade history chain.