Job DSL seed jobs trigger unwanted SCM scans on every run

Last Reviewed:2026-11-05()
2 minute readKnowledge base

Issue

A Job DSL seed job that manages an Organization Folder (or a folder containing multibranch Pipelines) triggers a full SCM source scan of every child item on every run of the seed job, even when the seed job makes no actual configuration changes. On controllers with many Organization Folders or multibranch Pipelines, this causes a "storm" of scan activity and SCM API calls each time the seed job runs. Reviewing the Scan Multibranch Pipeline Log for an affected item shows a scan was started that was not caused by a webhook, SCM polling, or the periodic folder trigger.

Legacy code started this job.  No cause information is available
▼

Environment

Explanation

Job DSL manages items by calling updateByXml on the folder or Organization Folder it owns. This causes a reload of the items contained in these folders, in particular Multibranch Pipelines. According to the Jenkins system properties documentation, reloading a Multibranch Pipeline item from XML "notifies its branch sources about it and triggers a scan if possible." This happens during an onLoad call, regardless of whether the Multibranch Pipeline’s configuration actually changed. As long as the updatingByXml thread-local flag is set while onLoad is called, the scan is triggered, which is why a seed job that runs repeatedly without making real changes still triggers a scan of every child item each time.

This behavior is controlled by the boolean system property jenkins.branch.MultiBranchProject.fireSCMSourceBuildsAfterSave, which defaults to true. The same Jenkins documentation explicitly calls out this scenario: "When Job DSL manages the items, this can avoid triggering many scans, which can potentially cause a build storm," referring to setting the property to false.

The same notification that triggers the scan can also be used by the SCM source to do other setup work, such as registering webhooks or warming up caches. Disabling this property suppresses that setup work along with the unwanted scans. Before disabling it on a controller, confirm that the SCM source plugins in use (for example a Bitbucket, GitHub, or GitLab branch source) do not depend on this notification for functionality you rely on, such as automatic webhook registration.

Resolution

Set the JVM system property jenkins.branch.MultiBranchProject.fireSCMSourceBuildsAfterSave to false on the controller that runs the Job DSL seed job.

  1. Add the following system property to the controller’s JVM arguments:

    -Djenkins.branch.MultiBranchProject.fireSCMSourceBuildsAfterSave=false
    ▼

    For CloudBees CI on modern cloud platforms - managed controller, see How to add Java arguments to Jenkins on CloudBees CI Modern? for the steps to add a system property to a managed controller.

  2. Restart the controller so the new system property takes effect.

  3. Run the Job DSL seed job again and open the Scan Multibranch Pipeline Log for a previously affected item.

  4. Confirm there is no new scan that started with the line "Legacy code started this job."

References

This article is part of our Knowledge Base and is provided for guidance-based purposes only. The solutions or workarounds described here are not officially supported by CloudBees and may not be applicable in all environments. Use at your own discretion, and test changes in a safe environment before applying them to production systems.