Skip to content

[JENKINS-2671] Extra build triggered with no changes #511

Closed
Bug
Closed
[JENKINS-2671] Extra build triggered with no changes#511
Bug
Labels
component:subversion-pluginimported-jira-issuepriority:criticalresolution:fixed

Description

@jenkins-infra-bot
jenkins-infra-bot
opened on Nov 25, 2008

I guess the issue I'm reporting is loosly related to issues 688 & 692.

Config :-
---------
1) Using Hudson 1.262 on Solaris 10 machine.

Settings for project
--------------------
1) SVN Polled every 5 mintutes
2) Quiteperiod set to 5 minutes

Sequence of Steps :-
--------------------
1) Check-in Test1.properties at 10:00 AM
Hudson deducts changes on SVN and waits for the quite period (5 mins).

2) Check-in Test2.properties at 10:02 AM
After the first quite period, Hudson deducts another change on SVN and waits
again for quite period (5 mins)

3) After the second quite period, Hudson starts the build for the changes.

4) Hudson also STARTS ANOTHER BUILD even though there are no more changes on
SVN. The console output also shows that NO CHANGES were deducted since the
previous build.

Thanks
Bharath

Originally reported by bharathnair, imported from: Extra build triggered with no changes
  • assignee: mindless
  • status: Closed
  • priority: Critical
  • component(s): subversion-plugin
  • resolution: Fixed
  • resolved: 2009-02-16T13:58:30+00:00
  • votes: 0
  • watchers: 0
  • imported: 20251212-090250
Raw content of original issue 
I guess the issue I'm reporting is loosly related to issues 688 & 692.



Config :-
---------
1) Using Hudson 1.262 on Solaris 10 machine.



Settings for project
--------------------
1) SVN Polled every 5 mintutes 
2) Quiteperiod set to 5 minutes



Sequence of Steps :-
--------------------
1) Check-in Test1.properties at 10:00 AM
   Hudson deducts changes on SVN and waits for the quite period (5 mins).



2) Check-in Test2.properties at 10:02 AM
   After the first quite period, Hudson deducts another change on SVN and waits 
again for quite period (5 mins)   



3) After the second quite period, Hudson starts the build for the changes.



4) Hudson also STARTS ANOTHER BUILD even though there are no more changes on 
SVN. The console output also shows that NO CHANGES were deducted since the 
previous build.



Thanks
Bharath
  • environment: Platform: All, OS: All
1 attachment

Activity

  1. jenkins-infra-bot commented on Dec 29, 2008

    @jenkins-infra-bot
    jenkins-infra-bot
    on Dec 29, 2008
    Author
    mindless:
    • Original comment link
    • Raw content of original comment: 
      I can confirm this behavior.  What's happening:
      


      In case of equal SCM-poll schedule and quiet period: initial quiet period ends
and a build starts, and at the same time another SCM-poll starts.  The SCM-poll
thinks there are still new changes because it runs before the new build has a
chance to update the job workspace with the latest changes from the repository.
 So that build runs AND a new one is scheduled (quiet period begins).
      


      Another variation: if the quiet period is slightly longer than the SCM poll
schedule then a build never starts.. every SCM poll sees new changes and then
extends the quiet period of the waiting job, so the quiet period never completes.
      


      WORKAROUND to avoid either issue: always keep quiet period at least 5-15 seconds
shorter than any SCM-polling schedule/interval (however long SCM updates take).
 This gives the newly-started job time to update the job workspace before the
next SCM poll.
      


      SOLUTION for these issues?  Not sure.. perhaps some locking on the SCM-poll to
prevent it from running if a build has started, but not yet updated the
workspace.  There's already some locking code around SCM-poll, so maybe it could
be updated for this case.
For the 2nd variation, there are a few options:
      

        
	
      • don't extend quiet period.. this would allow a build to start.  easiest to
implement; small change in Queue.add()
        • 
	
      • to keep extend-QP the SCM-poll would need some way to distinguish
changes-vs-job-workspace from changes-since-last-poll, and only extend quiet
period for the latter.  not sure how this would work..
        •

    I can confirm this behavior. What's happening:

    In case of equal SCM-poll schedule and quiet period: initial quiet period ends
    and a build starts, and at the same time another SCM-poll starts. The SCM-poll
    thinks there are still new changes because it runs before the new build has a
    chance to update the job workspace with the latest changes from the repository.
    So that build runs AND a new one is scheduled (quiet period begins).

    Another variation: if the quiet period is slightly longer than the SCM poll
    schedule then a build never starts.. every SCM poll sees new changes and then
    extends the quiet period of the waiting job, so the quiet period never completes.

    WORKAROUND to avoid either issue: always keep quiet period at least 5-15 seconds
    shorter than any SCM-polling schedule/interval (however long SCM updates take).
    This gives the newly-started job time to update the job workspace before the
    next SCM poll.

    SOLUTION for these issues? Not sure.. perhaps some locking on the SCM-poll to
    prevent it from running if a build has started, but not yet updated the
    workspace. There's already some locking code around SCM-poll, so maybe it could
    be updated for this case.
    For the 2nd variation, there are a few options:

    • don't extend quiet period.. this would allow a build to start. easiest to
      implement; small change in Queue.add()
    • to keep extend-QP the SCM-poll would need some way to distinguish
      changes-vs-job-workspace from changes-since-last-poll, and only extend quiet
      period for the latter. not sure how this would work..

  2. jenkins-infra-bot commented on Feb 16, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Feb 16, 2009
    Author
    mindless:
    • Original comment link
    • Raw content of original comment: 
      Looked into this a bit.. my approach was to use ResourceController so poll won't
run at the same time as checkout/update.  Wrapping code in Runnables is a little
ugly, but this does work (unit test included; also tested in UI).  Feedback
appreciated on whether to commit this, or recommendation for alternate approach.

    Looked into this a bit.. my approach was to use ResourceController so poll won't
    run at the same time as checkout/update. Wrapping code in Runnables is a little
    ugly, but this does work (unit test included; also tested in UI). Feedback
    appreciated on whether to commit this, or recommendation for alternate approach.

  3. jenkins-infra-bot commented on Feb 16, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Feb 16, 2009
    Author
    mindless:
    • Original comment link
    • Raw content of original comment: 
      Created an attachment (id=566)
don't poll while checkout/update is running

    Created an attachment (id=566)
    don't poll while checkout/update is running

  4. jenkins-infra-bot commented on Feb 16, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Feb 16, 2009
    Author
    mindless:
    • Original comment link
    • Raw content of original comment: 
      guess I could simplify by using SCMTrigger.getLock() for locking from
AbstractProject.checkout, rather than using the ResourceController system.

    guess I could simplify by using SCMTrigger.getLock() for locking from
    AbstractProject.checkout, rather than using the ResourceController system.

  5. jenkins-infra-bot commented on Feb 16, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Feb 16, 2009
    Author
    mindless:
    • Original comment link
    • Raw content of original comment: 
      yes, that was much simpler.. going to commit using SCMTrigger.getLock() directly
in checkout() when a SCMTrigger is present.

    yes, that was much simpler.. going to commit using SCMTrigger.getLock() directly
    in checkout() when a SCMTrigger is present.

  6. jenkins-infra-bot commented on Feb 16, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Feb 16, 2009
    Author
    scm_issue_link:
    • Original comment link
    • Raw content of original comment: 
      Code changed in hudson
User: : mindless
Path:
 trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java
 trunk/hudson/main/test/src/test/java/hudson/triggers/SCMTriggerTest.java
 trunk/www/changelog.html
http://fisheye4.cenqua.com/changelog/hudson/?cs=15377
Log:
[FIXED JENKINS-2671] lock the SCMTrigger.getLock() in checkout() so polling won't occur
while the checkout/update is in progress.

    Code changed in hudson
    User: : mindless
    Path:
    trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java
    trunk/hudson/main/test/src/test/java/hudson/triggers/SCMTriggerTest.java
    trunk/www/changelog.html
    http://fisheye4.cenqua.com/changelog/hudson/?cs=15377
    Log:
    [FIXED JENKINS-2671] lock the SCMTrigger.getLock() in checkout() so polling won't occur
    while the checkout/update is in progress.

  7. jenkins-infra-bot
    closed this as completedon Feb 16, 2009
  8. jenkins-infra-bot
    added
    bug
    imported-jira-issue
    component:subversion-plugin
    resolution:fixed
    priority:critical
    and removed
    bug
    on Dec 12, 2025
  9. jenkins-infra-bot
    added the
    Bug
    issue type on Dec 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    component:subversion-pluginimported-jira-issuepriority:criticalresolution:fixed

    Type

    Bug

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions