This happened to us on a few jobs after upgrading our jenkins from 1.574 to 1.650 and the git plugin from 1.4.0 to 2.4.2. After a lot of digging I managed to reproduce it on a fresh setup. The trick is to have the git polling being performed on a slave with an older version of git, which in our case was 1.7.1, and have the master branch in the repository being completely detached from origin/master (the branches do not share any common history). I am not sure exactly how we have ended up in this state but the affected jobs have been around for a long time so someone may have done nasty things to the repositories and/or workspaces.
I have managed to reproduce it on a fresh setup by creating a buildslave running on Centos 6.7 which comes with git 1.7.1. I then tied a job to to that build slave. I had to edit the job's config.xml to get it into the same state as our production job and I'm not sure exactly what setting causes it to start running the git polling on the build slave but here is the config.xml which reproduces this:
<?xml version='1.0' encoding='UTF-8'?>
<project>
<actions/>
<description></description>
<keepDependencies>false</keepDependencies>
<properties>
<hudson.model.ParametersDefinitionProperty>
<parameterDefinitions>
<hudson.model.TextParameterDefinition>
<name>TAG</name>
<description></description>
<defaultValue>master</defaultValue>
</hudson.model.TextParameterDefinition>
</parameterDefinitions>
</hudson.model.ParametersDefinitionProperty>
<hudson.plugins.throttleconcurrents.ThrottleJobProperty plugin="throttle-concurrents@1.8.4">
<maxConcurrentPerNode>0</maxConcurrentPerNode>
<maxConcurrentTotal>0</maxConcurrentTotal>
<throttleEnabled>false</throttleEnabled>
<throttleOption>project</throttleOption>
</hudson.plugins.throttleconcurrents.ThrottleJobProperty>
</properties>
<scm class="hudson.plugins.git.GitSCM" plugin="git@2.4.2">
<configVersion>2</configVersion>
<userRemoteConfigs>
<hudson.plugins.git.UserRemoteConfig>
<name>origin</name>
<refspec>+refs/heads/*:refs/remotes/origin/*</refspec>
<url>https://github.com/Cantemo/RSSFeedWidget.git</url>
</hudson.plugins.git.UserRemoteConfig>
</userRemoteConfigs>
<branches>
<hudson.plugins.git.BranchSpec>
<name>${TAG}</name>
</hudson.plugins.git.BranchSpec>
</branches>
<doGenerateSubmoduleConfigurations>false</doGenerateSubmoduleConfigurations>
<submoduleCfg class="list"/>
<extensions>
<hudson.plugins.git.extensions.impl.PerBuildTag/>
<hudson.plugins.git.extensions.impl.AuthorInChangelog/>
</extensions>
</scm>
<assignedNode>buildslave-co67</assignedNode>
<canRoam>false</canRoam>
<disabled>false</disabled>
<blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
<blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
<triggers>
<hudson.triggers.SCMTrigger>
<spec>* * * * *</spec>
<ignorePostCommitHooks>false</ignorePostCommitHooks>
</hudson.triggers.SCMTrigger>
</triggers>
<concurrentBuild>false</concurrentBuild>
<builders/>
<publishers/>
<buildWrappers/>
</project>
I then let the job check out a git repository and start polling on the slave. Once that had completed I logged into the build slave and ran
in the workspace. After this I changed the repository url to point to another repository and after that, I started to get new build jobs spawned every 60 seconds.
The first repository I used was https://github.com/Cantemo/PortalPluginTemplate.git and the second one was https://github.com/Cantemo/RSSFeedWidget.git
This is the git polling log:
The output from the commands above is:
commit e8adac91f3872ad7fe6fdf4ec84951af86e03e6a is master in repo https://github.com/Cantemo/RSSFeedWidget.git
commit 5d99e8ae6e989be1c3cd568c25701b9c15abf2e6 is master in repo https://github.com/Cantemo/PortalPluginTemplate.git
In the end, wiping the workspaces on the affected jobs stops the looping builds.
Sorry that it went into a loop building the same commit repeatedly.
Unfortunately, I don't know how to duplicate the problem you're describing. Can you duplicate the problem on a freshly installed system, then share the duplication steps? If you want an easy starting point, you might consider the official Jenkins docker image, or if you'd prefer an image configured with the plugins that I often use, you could start with my master with plugins docker image.
Is there a reason you're running the very latest weekly build of Jenkins but running git plugin and git client plugin versions from a year ago?
You suggest that the "pre-build made Jenkins decide it needed to do another build". Can you explain further what you mean by that, and what you observed?