[JIRA] [git-plugin] (JENKINS-17614) Jenkins triggers builds on git SCM changes, but nothing changed

24 views
Skip to first unread message

W.BelgraverThissen@SpiritIT.com (JIRA)

unread,
Jul 2, 2015, 3:57:03 AM7/2/15
to jenkinsc...@googlegroups.com
Wilco Belgraver Thissen commented on Bug JENKINS-17614
 
Re: Jenkins triggers builds on git SCM changes, but nothing changed

I see similar behaviour but it seems for me to be triggered by deleting workspaces. I now in the past I saw it happen when I did it manually but now we have a bunch of variants that need to be build sporadic but have huge workspaces so I added the automatic delete final step and I have the feeling this is triggering the change detection.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

djr_new@yahoo.in (JIRA)

unread,
Jul 7, 2015, 11:53:02 PM7/7/15
to jenkinsc...@googlegroups.com

Im facing similar issue. I have jenkins - 1.584 and Git plugin - 2.33.
Following are the behaviours

– No polling is configured. But build is triggered automatically as 'SCM change'. Nothing is displayed in the polling logs.
– When i trigger a build, another SCM trigger build follows up with that.
– SCM triggered build deletes the workspace.

mark.earl.waite@gmail.com (JIRA)

unread,
Jul 8, 2015, 12:40:03 AM7/8/15
to jenkinsc...@googlegroups.com

Jeevarathinam Dhanapal I believe you are describing a different condition than this one. All the other descriptions of this bug require polling to be enabled. You say that polling is disabled. If polling is disabled, then builds should not be triggered as "SCM change" as far as I know.

I don't understand why an SCM triggered build would delete the workspace, unless you've configured something to delete the workspace. The git plugin does not have any ability to delete the workspace after a build. It can delete a workspace immediately before a build, but not after a build.

djr_new@yahoo.in (JIRA)

unread,
Jul 8, 2015, 3:06:02 AM7/8/15
to jenkinsc...@googlegroups.com

@Mark Waite - My job wipes the workspace and could agree that its not from the git plugin. But definitely job doesn't have configuration for Polling.
I see someone posted similar observation before in the same thread.

"mika Michael Prokop added a comment - 08/Aug/13 11:11 AM
Same here (Jenkins ver. 1.525 with Git Plugin and several other plugins, but noticed this behaviour also in older versions), seeing "Started by an SCM change" and an empty pollingLog in the job that was triggered even though it shouldn't have been triggered at all as "Poll SCM" is disabled."

djr_new@yahoo.in (JIRA)

unread,
Jul 8, 2015, 3:07:02 AM7/8/15
to jenkinsc...@googlegroups.com
@ # Mark Waite - My job wipes the workspace and could agree that its not from the git plugin. But definitely job doesn't have configuration for Polling. 

I see someone posted similar observation before in the same thread.

"mika Michael Prokop added a comment - 08/Aug/13 11:11 AM
Same here (Jenkins ver. 1.525 with Git Plugin and several other plugins, but noticed this behaviour also in older versions), seeing "Started by an SCM change" and an empty pollingLog in the job that was triggered even though it shouldn't have been triggered at all as "Poll SCM" is disabled."

djr_new@yahoo.in (JIRA)

unread,
Jul 8, 2015, 3:07:05 AM7/8/15
to jenkinsc...@googlegroups.com
#Mark Waite [~markewaite]  - My job wipes the workspace and could agree that its not from the git plugin. But definitely job doesn't have configuration for Polling. 

I see someone posted similar observation before in the same thread.

"mika Michael Prokop added a comment - 08/Aug/13 11:11 AM
Same here (Jenkins ver. 1.525 with Git Plugin and several other plugins, but noticed this behaviour also in older versions), seeing "Started by an SCM change" and an empty pollingLog in the job that was triggered even though it shouldn't have been triggered at all as "Poll SCM" is disabled."

mark.earl.waite@gmail.com (JIRA)

unread,
Jul 8, 2015, 8:26:10 AM7/8/15
to jenkinsc...@googlegroups.com

Jeevarathinam Dhanapal since this bug report includes a screen shot with a polling log, and the only way that I know to have a polling log is to enable polling, I assume that the comment you quoted is about a different bug. It is a bug, but I've not seen any way to duplicate the bug and I generally can't safely fix a bug which I can't duplicate.

patryk.szczech@gmail.com (JIRA)

unread,
Aug 7, 2015, 10:07:04 AM8/7/15
to jenkinsc...@googlegroups.com

Hey, I'm facing the same issue.
I've created new job with multiple git scm. In all repositories I checked the option "don't trigger a build on commit notifications", but job is still triggering itself, one ofter the other, with "Started by an SCM change". There is no hooks set on our gitlab. The option "Ignore post-commit hooks" in Poll SCM doesn't work too. It seems that job is triggering without any reason.

ismith@aminocom.com (JIRA)

unread,
Aug 14, 2015, 6:22:07 AM8/14/15
to jenkinsc...@googlegroups.com

Hi,

I am also having the same issue where a build is started even though there has been no commit between the two times and the git tag is exactly the same.

So for build#263 from the "Started by SCM change" link I have

Started on 13-Aug-2015 15:39:59
Using strategy: Default
[poll] Last Built Revision: Revision 9cca12842f5b191d37e48a0ac2a1b7a2a87368e1 (origin/master)
Done. Took 29 ms
Changes found

And for build#264 I get

Started on 13-Aug-2015 16:09:59
Using strategy: Default
[poll] Last Built Revision: Revision 9cca12842f5b191d37e48a0ac2a1b7a2a87368e1 (origin/master)
Done. Took 44 ms
Changes found

Note that the GIT tag is identical in both cases and it is using the same branch. So how is this deciding that there is a change?

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 14, 2015, 7:25:02 AM8/14/15
to jenkinsc...@googlegroups.com

Ian Smith and Patryk Szczęch can you provide steps which show how to duplicate the problem?

patryk.szczech@gmail.com (JIRA)

unread,
Aug 14, 2015, 7:35:40 AM8/14/15
to jenkinsc...@googlegroups.com

Actually I do. I think I found the problem. In git plugin by default /master branch is set to build from. I've noticed that someone commited and pushed a branch named origin/master to gitlab. I think that Jenkins somehow gets confused when it finds two branches matching the pattern (/master), so it triggers the job constantly. I don't know if it should work that way, but I guess you can now try to reproduce the problem. I had the newest version of Jenkins back then, which was 1.621. Hope it will help you!

patryk.szczech@gmail.com (JIRA)

unread,
Aug 14, 2015, 7:42:01 AM8/14/15
to jenkinsc...@googlegroups.com

I did't mean to bold the text. I meant to put the star sign (asteriks)

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 14, 2015, 8:10:04 AM8/14/15
to jenkinsc...@googlegroups.com

Steps I took to duplicate the problem:

  1. Create a bare repository /var/lib/git/mwaite/bugs/JENKINS-17614.git
  2. Clone the bare repository, add a README, and push the README to the bare repository
  3. Define a Jenkins job which polls that bare repository
  4. Commit another change to the bare repository, confirm the polling detects the repository and builds the job
  5. Create a branch named "origin/master" and push it to the bare repository, confirm the job builds never stop

I'm hopeful that is not the case also seen by the original submitter of the bug report, but at least I know one way to show the problem.

patryk.szczech@gmail.com (JIRA)

unread,
Aug 14, 2015, 8:28:01 AM8/14/15
to jenkinsc...@googlegroups.com

Mark Waite, why are you hopeful it's not it? And is this working the way it should, or it is actually a bug?

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 14, 2015, 8:33:02 AM8/14/15
to jenkinsc...@googlegroups.com

I think it is a bug, but also an uncommon case. I don't plan to spend any further time investigating the bug since I believe that single case is low probability and there are other bugs which are higher risk of being seen by many users.

W.BelgraverThissen@SpiritIT.com (JIRA)

unread,
Aug 17, 2015, 8:54:02 AM8/17/15
to jenkinsc...@googlegroups.com

I think there are more scenario's then this one.
I have a job that depends on a bunch of repositories, all to branch "*/fc_1.8-bugfix" and scheduled it to check for changes on the schedule "H 18-23,0-6 * * *" and automatically delete workspace before and after.
If I then look at the detected changes the last one are listed for build 55 but I also have this list of builds:
#5​8 17-aug-2015 9:57
#5​7 16-aug-2015 23:05
#5​6 16-aug-2015 7:46
#5​5 15-aug-2015 11:04
So it started 3 more times while nothing changed.

So nothing involving "origin/master" . If I list all the branches of all the repositories involved here then I only see these 2 lines containing "master":
remotes/origin/HEAD -> origin/master
remotes/origin/master

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 17, 2015, 12:15:03 PM8/17/15
to jenkinsc...@googlegroups.com

Wilco Belgraver Thissen I also think there are more scenarios than the case of the badly named branch. However, yours is the first attempt to describe another case with enough detail that others can duplicate the problem. Have you checked that your case is repeatable on a fresh Jenkins installation?

If you'd like the convenience of a docker instance to run that test, you could use the master-with-plugins docker instance plugin that I use for my quick setup and teardown of test Jenkins instances.

W.BelgraverThissen@SpiritIT.com (JIRA)

unread,
Sep 11, 2015, 4:01:15 AM9/11/15
to jenkinsc...@googlegroups.com

Sorry, but that is not exactly trivial in the environment here and I don't see when we will have a sprint that there is time available for this, the coming weeks look overfull already.

ann.campbell@shawinc.com (JIRA)

unread,
Jan 7, 2016, 11:18:04 AM1/7/16
to jenkinsc...@googlegroups.com

I just encountered this problem and fixed it by updating branch from the default ** to a specific branch name, "master" in my case.

ann.campbell@shawinc.com (JIRA)

unread,
Jan 7, 2016, 11:19:03 AM1/7/16
to jenkinsc...@googlegroups.com
G. Ann Campbell edited a comment on Bug JENKINS-17614
I just encountered this problem  (on Cloudbees, so I don't know the versin #)  and fixed it by updating branch from the default {{**}} to a specific branch name, "master" in my case.

ismith@aminocom.com (JIRA)

unread,
Jan 13, 2016, 3:38:03 AM1/13/16
to jenkinsc...@googlegroups.com

I've managed to trigger this problem again on 1.598 of Jenkins with the git client plugin v1.6.4 and git plugin v2.0.4. What seems to be the trigger is doing a git cherry-pick -x from HEAD to a branch and the building of the branch via an SCM update resulting in multiple builds.

I don't know if it's the extra git commit at the bottom of the message that causes the issue but I haven't seen this issue for a while which corresponds to a lack of backports from HEAD to a version branch.

Method to re-create

1. Push a fix to HEAD
2. Cherry pick the change to a branch using

git cherry-pick -x 2bedf18808f066a29d84bcb3301308cd6b81d0fe

3. This produces a commit similar to

Commit header

Commit message
...
(cherry picked from commit 2bedf18808f066a29d84bcb3301308cd6b81d0fe)

4. Wait for the SCM update to trigger on the branch
5. As the poll is set to every 5 minutes I then get a new build started every 5 minutes as it seems that Jenkins seems to think the last build was the one done before the cherry-pick and keeps spinning more builds.

I'm wondering if the extra commit reference at the end is confusing the parser.

ampleyfly@gmail.com (JIRA)

unread,
Jan 13, 2016, 5:16:02 AM1/13/16
to jenkinsc...@googlegroups.com

This but is about jenkins triggering builds of jobs which do not use SCM polling, yet indicating that an SCM change was the cause. Why is everyone discussing unrelated problems? Should I create a new bug to get a clean look at this?

ampleyfly@gmail.com (JIRA)

unread,
Jan 13, 2016, 5:17:02 AM1/13/16
to jenkinsc...@googlegroups.com
Simon Johansson edited a comment on Bug JENKINS-17614
This  but  bug  is about  jenkins  Jenkins  triggering builds of jobs which _do not_ use SCM polling, yet indicating that an SCM change was the cause. Why is everyone discussing unrelated problems? Should I create a new bug to get a clean look at this?

mark.earl.waite@gmail.com (JIRA)

unread,
Jan 13, 2016, 6:31:03 AM1/13/16
to jenkinsc...@googlegroups.com

Yes, Simon Johansson, please create a separate bug report with specific steps which show the problem on a fresh installation of Jenkins and the git plugin and which specifically states that SCM polling must not be configured seems very reasonable to me.

I've made at least one mistaken comment on this bug report assuming that polling was enabled, even though the original submitter clarified that polling was not enabled on the job which originally prompted this bug report.

I'm unlikely to spend more time on this bug report without those steps, since I've not yet seen a numbered series of steps which clearly duplicate the problem.

ampleyfly@gmail.com (JIRA)

unread,
Jan 13, 2016, 8:17:02 AM1/13/16
to jenkinsc...@googlegroups.com

Unfortunately, I no longer encounter this bug, and I have no idea what caused it, so can't reproduce.

I think it's a good tip for the next person to come across this to follow Mark Waite's advice and create a new, detailed bug, with steps to reproduce the problem.

ampleyfly@gmail.com (JIRA)

unread,
Feb 12, 2016, 8:43:03 AM2/12/16
to jenkinsc...@googlegroups.com

I have encountered the problem I had again, and this time figured out why it happened. Of course, I cannot be sure this is what happened to the original bug reporter.

We use a parameter for specifying which branch to build. If this parameter is empty for any reason, the SCM build step starts new builds for all branches it can find in that repository. These new builds start without any parameter values, and so cause the same problem with any other repositories used in the same way. All builds started this way are marked as having been started by an SCM change.

This is not a bug, since the plugin clearly states this is what is supposed to happen if you don't supply a branch.

In my case, the cause was slightly masked by the way our jobs are set up. There's some jobs A, B and C. Job A does some work, then runs job B with some parameters, which are then forwarded to job C. If B fails for any reason, the idea is that it can be rebuilt, without having to run the steps in A again. The problem occurs when C needs some parameter which B does not list as a parameter of its own. If B is rebuilt, this parameter will not get a value when C is called, and so the whole build avalanche starts.

kamal2222ahmed@yahoo.com (JIRA)

unread,
Mar 23, 2016, 4:29:04 PM3/23/16
to jenkinsc...@googlegroups.com

We have an auto merge job which gets triggered by a Build-A and Build-Test-B jobs not by scm changes, and due to this bug, it was randomly picking up commits from 6 months ago, with random git hashes. so as per THIS use case, you DO need to fix this. You should have the option of having allowing no/null branch or hash. like a checkbox. It should appropriately exit accordingly.

mark.earl.waite@gmail.com (JIRA)

unread,
Mar 23, 2016, 4:39:03 PM3/23/16
to jenkinsc...@googlegroups.com

Kamal Ahmed you'll need to provide much more detail before anyone will be persuaded to take their time to investigate and work on the problem you're reporting. I'd advise you to create a numbered series of steps which start with a fresh Jenkins installation, the latest version of the git plugin, and show the problem. Use those steps to create a new bug report, since it is likely a very different scenario than the one described originally in this bug report.

I suggested a few months ago that anyone who encounters what they believe to be an instance of this bug should provide detailed steps that illustrate the problem and submit a new bug report. This particular bug report requires that SCM polling is not enabled, and does not seem to report anywhere that it was selecting random commits from 6 months ago. Your comments says that the job was triggered by another job and was retrieving random commits.

mark.earl.waite@gmail.com (JIRA)

unread,
Mar 23, 2016, 4:40:03 PM3/23/16
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-17614
[~kamal2222ahmed] you'll need to provide much more detail before anyone will be persuaded to take their time to investigate and work on the problem you're reporting.  I'd advise you to create a numbered series of steps which start with a fresh Jenkins installation, the latest version of the git plugin, and show the problem.  Use those steps to create a new bug report, since it is likely a very different scenario than the one described originally in this bug report.

I suggested a [few months ago|https://issues.jenkins-ci.org/browse/JENKINS-17614?focusedCommentId=245832&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-245832] that anyone who encounters what they believe to be an instance of this bug should provide detailed steps that illustrate the problem and submit a new bug report.  This particular bug report requires that SCM polling is not enabled, and does not seem to report anywhere that it was selecting random commits from 6 months ago.  Your comments says that the job was triggered by another job and was retrieving random commits.


You might also consider evaluating the "Ancestry" build chooser which is available in the git plugin under "Strategy for choosing what to build".  That alternate build chooser allows you to limit the age of commits which will be considered.

benshadwick@gmail.com (JIRA)

unread,
Nov 3, 2016, 10:59:03 AM11/3/16
to jenkinsc...@googlegroups.com

I'm seeing this with the MultiSCM plugin: My project pulls from half a dozen Git repos on two different servers. One of the servers provides post-commit notifications to Jenkins for 3 of the repos.

If commits occur to two of the notifying repos in a short timeframe (which is often the case, as one repo contains shared code and the other contains specific code+data), Jenkins picks up all changes in one build, then immediately does a second build with "no SCM changes".

Seems like there should be a way to ignore notifications iff there are no changes detected?

This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

owen@nerdnetworks.org (JIRA)

unread,
Jan 13, 2017, 7:31:02 PM1/13/17
to jenkinsc...@googlegroups.com

Mark Waite just wanted to say that I ran into this bug today, and your comment where you figured out that having a branch named 'origin/master' causes endless builds saved me We did indeed have such a rogue branch, and deleting it fixed the problem.

I also want to add that the "rogue" builds all said they were "Started by an SCM change," even though we do not have SCM polling enabled. And the polling log in the Jenkins UI (/pollingLog) was empty. But the polling.log files on the master, for all builds, said e.g., "This build was triggered by build 284 because more than one build candidate was found." In other words they were endlessly triggered by the previous build. Maybe that's also a bug, the fact that this was written to the polling log? And maybe it does not display in the UI because Jenkins sees that the job is not configured for polling? I'm not sure if that information is of any use to you, but I didn't see it anywhere else in this bug report.

Thanks as always for your continued work on the Git plugin!

owen@nerdnetworks.org (JIRA)

unread,
Jan 13, 2017, 7:34:02 PM1/13/17
to jenkinsc...@googlegroups.com
Owen Mehegan edited a comment on Bug JENKINS-17614
[~markewaite] just wanted to say that I ran into this bug today, and your comment where you figured out that having a branch named 'origin/master' causes endless builds saved me :)  We did indeed have such a rogue branch, and deleting it fixed the problem.

I also want to add that the "rogue" builds all said they were "Started by an SCM change," even though we do not have SCM polling enabled. And the polling log in the Jenkins UI (/pollingLog) was empty. But the polling.log files on the master, for all builds, said e.g., "This build was triggered by build 284 because more than one build candidate was found." In other words they were endlessly triggered by the previous build. Maybe that's also a bug, the fact that this was written to the polling log? And maybe it does not display in the UI because Jenkins sees that the job is not configured for polling? I'm not sure if that information is of any use to you, but I didn't see it anywhere else in this bug report.
The initial run of this job was triggered by the Jenkins API.

Thanks as always for your continued work on the Git plugin!

mark.earl.waite@gmail.com (JIRA)

unread,
Jan 13, 2017, 7:39:03 PM1/13/17
to jenkinsc...@googlegroups.com

Owen Mehegan thanks for the further details on the failure mode that you saw.

f.ld@free.fr (JIRA)

unread,
Jan 30, 2017, 4:06:02 AM1/30/17
to jenkinsc...@googlegroups.com

Reading all this because we had the same issue: a job without SCM polling configured continuously being triggered for an SCM change. And the reason was the same as for [Owen Mehegan] above:

 * [new branch]      origin/master -> origin/origin/master

A dev committed and pushed a new branch with name `origin/master`
Note: we have another job with SCM polling from the same repository and that was also triggered continuously for no reason. I can understand why this one was mistaken, not why the one with no SCM polling could be

ignacio.serrano@gft.com (JIRA)

unread,
Feb 23, 2017, 4:39:04 AM2/23/17
to jenkinsc...@googlegroups.com

I had the same issue. My branch was specified as «lspa/$

{APP_NAME}». Polling was disabled, and my polling log didn't display any changes.

It fixed when I changed it to «refs/heads/lspa/${APP_NAME}

».

ignacio.serrano@gft.com (JIRA)

unread,
Feb 23, 2017, 4:40:08 AM2/23/17
to jenkinsc...@googlegroups.com

kerrhome (JIRA)

unread,
Jul 13, 2018, 4:12:02 PM7/13/18
to jenkinsc...@googlegroups.com

I'm seeing this same behavior and we're using Subversion.  Latest LTS and latest plugins.  Almost every one of our trunk builds is triggered nightly and fails because the readme file wasn't update per our requirements.  When I recently went to the latest Jenkins LTS and Subversion plugin, it now seems that it is happening every single night (we trigger a nightly build for the product only if there were changes).  I've got some irritated managers here and I have no explanation.  The changes list is empty, but I do see "Changes found" at the end of the polling log.  No errors in the system log.  Should I raise a separate ticket for this? I think this post is on to something (for me at least) as it does appear that the polling log is looking at everything since the last successful pipeline build: https://issues.jenkins-ci.org/browse/JENKINS-17614?focusedCommentId=190266&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-190266

This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

mark.earl.waite@gmail.com (JIRA)

unread,
Jul 13, 2018, 4:22:03 PM7/13/18
to jenkinsc...@googlegroups.com

Shannon Kerr submit a separate ticket.

This ticket is assigned to the git plugin. If a change were made to address it, it would be in the git plugin. That wouldn't help your case, since you're not using the git plugin.

kerrhome (JIRA)

unread,
Oct 1, 2018, 4:05:03 PM10/1/18
to jenkinsc...@googlegroups.com

I did just submit a ticket (JENKINS-53839), Mark Waite. Thanks.  I wasn't sure if there was some common SCM API that could be the culprit here.

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

marlene.cote@keurig.com (JIRA)

unread,
Oct 17, 2018, 1:54:02 PM10/17/18
to jenkinsc...@googlegroups.com

I am seeing a very odd behavior that seems to have just started out of the blue.  I have a multijob job that does NO polling at all.  It is meant to be kicked off manually and depends on many parameters to be set by the user.  It is being kicked off randomly saying it was started by an SCM change.  since the parameters are not set properly, it fails.  Why is this build getting kicked off by scm changes when I don't using polling?

marlene.cote@keurig.com (JIRA)

unread,
Oct 17, 2018, 1:57:02 PM10/17/18
to jenkinsc...@googlegroups.com
marlene cote edited a comment on Bug JENKINS-17614
I am seeing a very odd behavior that seems to have just started out of the blue.  I have a multijob job that does NO polling at all.  It is meant to be kicked off manually and depends on many parameters to be set by the user.  It is being kicked off randomly saying it was started by an SCM change.  since the parameters are not set properly, it fails.  Why is this build getting kicked off by scm changes when I don't using polling?


jenkins version: 2.121.3

git plugin version: 3.9.1

marlene.cote@keurig.com (JIRA)

unread,
Oct 17, 2018, 2:06:03 PM10/17/18
to jenkinsc...@googlegroups.com
marlene cote edited a comment on Bug JENKINS-17614
I am seeing a very odd behavior that seems to have just started out of the blue.  I have a multijob job that does NO polling at all.  It is meant to be kicked off manually and depends on many parameters to be set by the user.  It is being kicked off randomly saying it was started by an SCM change.  since the parameters are not set properly, it fails.  Why is this build getting kicked off by scm changes when I don't using polling?

!image-2018-10-17-14-03-19-028.png!

when I click on the Started by an SCM change link, it brings me to a polling log that is empty. 

!image-2018-10-17-14-04-05-260.png!

 

jenkins version: 2.121.3

git plugin version: 3.9.1

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 17, 2018, 3:47:06 PM10/17/18
to jenkinsc...@googlegroups.com

marlene cote a question asked on a bug report has much less chance of a response than a question asked in one of the chat systems or on the mailing list. Fewer people read the bug reports than read the chat system and the mailing list.

I don't know why it reports "started by an SCM change". That is usually an indicator that a notifyCommit was received or that a webhook was called.

marlene.cote@keurig.com (JIRA)

unread,
Oct 17, 2018, 4:02:04 PM10/17/18
to jenkinsc...@googlegroups.com

Mark,

thanks for the advice.  your comment actually led me right to the culprit. a hook on one of my Bitbucket repos.  thank you!

Marlene

Senthilkumar.Palanisamy@in.bosch.com (JIRA)

unread,
Feb 13, 2019, 12:01:04 AM2/13/19
to jenkinsc...@googlegroups.com

Team,

We are also facing the same issue Job started triggering due to SCM continuously, but no actual change in code. Please can we know if any workaround or any fix is available.

Jenkins version --->2.89.4

Git Plugin version --> 3.9.1

Thanks
Senthil

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 13, 2019, 4:18:02 AM2/13/19
to jenkinsc...@googlegroups.com

Senthilkumar Palanisamy you can attempt the following workarounds as possible alternatives:

  • Copy the existing job to a new name, check if the continuous builds happen in the new job or not
  • Wipe the workspace of the existing job
  • Modify the existing job to poll only a single branch rather than a wildcard branch name
  • Modify the existing job to require a local workspace

Those are all only temporary workarounds, but worth trying to see if they will let you avoid the bug you're seeing.

opalldana@yahoo.com (JIRA)

unread,
Mar 25, 2019, 9:45:06 AM3/25/19
to jenkinsc...@googlegroups.com
dana j commented on Bug JENKINS-17614

Facing the same issue. Using Jenkins 2.167 & GitPlugin, a pipeline job without any webhook/notifiyCommit and Poll SCM (enabled to check for changes only on master every hour). However, a build is triggered nightly logging "Started by an SCM change" even though there are no changes.
Mark Waite - tried out the 4 suggested workarounds, but no change in behavior.

rkenney@moesol.com (JIRA)

unread,
May 13, 2019, 10:24:04 PM5/13/19
to jenkinsc...@googlegroups.com

Is it possible to inspect whatever the git plugin uses to track which git hashes it hass built so far? I can't seem to find this anywhere on my jenkins master. Presumably it has to be persisted to disk on the master.. somewhere.

 

dana.maxfield@gmail.com (JIRA)

unread,
May 16, 2019, 10:21:20 AM5/16/19
to jenkinsc...@googlegroups.com

We continue to randomly hit this issue. When I created a new release branch, one that isn't being built by the build in question, the problem building started triggering on every poll. If I delete the release branch, triggering stops. No traces of the release branch exist within the problem build configuration OR source.

Mark Waite I have also tried all of the work arounds you supplied (thank you btw), but none have worked. Is any data stored on the file system that I can delete or edit which will flush this out?

mark.earl.waite@gmail.com (JIRA)

unread,
May 16, 2019, 10:25:16 AM5/16/19
to jenkinsc...@googlegroups.com

Dana Maxfield I don't know of any other work arounds beyond those that I listed earlier.

a.g.salnikov@gmail.com (JIRA)

unread,
Jun 19, 2019, 6:03:07 AM6/19/19
to jenkinsc...@googlegroups.com

pazzinivinicius@gmail.com (JIRA)

unread,
Jul 16, 2019, 9:19:03 AM7/16/19
to jenkinsc...@googlegroups.com

mark.earl.waite@gmail.com (JIRA)

unread,
Jul 16, 2019, 9:23:13 AM7/16/19
to jenkinsc...@googlegroups.com

383648486@qq.com (JIRA)

unread,
Jul 19, 2019, 2:37:15 AM7/19/19
to jenkinsc...@googlegroups.com
Nina Jiang updated an issue
 
Jenkins / Bug JENKINS-17614
Change By: Nina Jiang
Attachment: image-2019-07-19-14-35-59-774.png

383648486@qq.com (JIRA)

unread,
Jul 19, 2019, 2:38:05 AM7/19/19
to jenkinsc...@googlegroups.com
Nina Jiang updated an issue
Change By: Nina Jiang
Attachment: image-2019-07-19-14-37-37-789.png

383648486@qq.com (JIRA)

unread,
Jul 19, 2019, 2:43:03 AM7/19/19
to jenkinsc...@googlegroups.com
Nina Jiang commented on Bug JENKINS-17614
 
Re: Jenkins triggers builds on git SCM changes, but nothing changed

Recently I got into this issue and fix it by identify the right 'Branch Specifier '.

Set the 'Branch Specifier ' as '*/dev' will cause the problem because I have a local branch called 'local/dev' and the auto-pull won't update the local branch.

Set the 'Branch Specifier ' as 'remotes/origin/dev', the poll SCM get back to normal.

 

 

383648486@qq.com (JIRA)

unread,
Jul 19, 2019, 3:19:05 AM7/19/19
to jenkinsc...@googlegroups.com
Nina Jiang updated an issue
Change By: Nina Jiang
Attachment: image-2019-07-19-14-35-59-774.png

383648486@qq.com (JIRA)

unread,
Jul 22, 2019, 10:25:17 AM7/22/19
to jenkinsc...@googlegroups.com
Nina Jiang updated an issue
Change By: Nina Jiang
Attachment: image-2019-07-19-14-37-37-789.png

383648486@qq.com (JIRA)

unread,
Jul 22, 2019, 10:25:17 AM7/22/19
to jenkinsc...@googlegroups.com
Nina Jiang edited a comment on Bug JENKINS-17614
Recently I got into this issue and fix it by identify the right 'Branch Specifier '.

Set the 'Branch Specifier ' as '*/dev' will cause the problem because I have a local branch called 'local/dev' and the auto-pull won't update the local branch.

Set the 'Branch Specifier ' as ' remotes/ origin/dev', the poll SCM get back to normal. :)

!image-2019-07-19-14-37-37-789.png!

 

 

samuel.zihlmann@deimos.ch (JIRA)

unread,
Nov 25, 2019, 6:07:04 AM11/25/19
to jenkinsc...@googlegroups.com

I had the same problem with some feature branches, but after setting 'Branch Specifier' with 'refs/heads/feature/...' and not only 'feature/...' everything works fine now.

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages