Issue

As part of your build process, your Jenkins job has to commit a change back to your SCM repo (for example a Changelog entry or incrementing a version number). But this commit triggers a new Jenkins build, resulting in the job building over and over endlessly.

Environment

• CloudBees CI (CloudBees Core)
• CloudBees CI (CloudBees Core) on modern cloud platforms - Managed controller
• CloudBees CI (CloudBees Core) on modern cloud platforms - Operations Center
• CloudBees CI (CloudBees Core) on traditional platforms - Client controller
• CloudBees CI (CloudBees Core) on traditional platforms - Operations Center
• CloudBees Jenkins Platform - Client controller
• CloudBees Jenkins Platform - Operations Center
• CloudBees Jenkins Distribution
• Jenkins LTS

Resolution

To avoid this, you must configure your Jenkins job to ignore commits that are made by the SCM user that Jenkins uses to check out your repo. For Freestyle or non-Multibranch Pipeline jobs you would use the “Polling ignores commits from certain users” option. For Pipeline Multibranch jobs you would use the Ignore Committer Strategy plugin, which will let you configure this at the level of individual jobs or for an entire folder/namespace of jobs. Once this is done Jenkins builds can commit back to the repo and although those commits will trigger a webhook or polling event to Jenkins, the commits will be ignored and the build will not trigger.