MultiSourceControl and Git causes frequent rebuilds with no modifications (Bug #309)

Added by Kenneth Jensen almost 5 years ago. Updated almost 4 years ago.

Status:Closed Start date:09/12/2013
Priority:Normal Due date:
Assignee:Ruben Willems % Done:


Category:- Spent time: -
Target version:1.8.5
Affected version:1.8.4


While debugging some problems with CCnet and git I stumbled upon something that looks like unintended behavior, but I'm not sure if it's bad configuration or my expectations that are wrong.

I started out with the demo ccnet.config and added a multi source control block with two git repositories.
The repos are made for testing, so each one has just one text file with 2 commits. They are located locally on the same drive as CCnet is running from.
My "build" is just the ping action from the demo script.

The behavior I'm seeing is that at first integration the repos are cloned, thus there are modifications, and the build is triggered.
Second integration run there are no modifications - which is expected.
But the third run, CCnet finds that there are modifications, so the build is triggered.
From here on, it runs a steady rhythm - every other integration, CCnet sees changes and triggers the build (and the repositories are not changed).

If I have just one sourcecontrol of type git, then everything works as expected - build is only triggered when I change the repository.

As far as I can see, the method MultiSourceControl.GetModifications(IIntegrationResult from, IIntegrationResult to) modified the from.SourceControlData list, so every other time it has only 1 of the 2 actual source-control-objects, and that triggers the build. I have a tiny patch that fixes the issue and doesn't break any unit tests.

To reproduce, create two repos as
mkdir test1; cd test1; git init; echo 123 > file.txt; git commit -m "first"; echo 321 >> file.txt; git commit -m "second"
mkdir test2; cd test2; git init; echo 123 > file.txt; git commit -m "first"; echo 321 >> file.txt; git commit -m "second"

ccnet config:

<state type="state" directory="State" />

<intervalTrigger name="continuous"

<sourcecontrol type="multi">

<!-- if you want the task to fail, ping an unknown server -->
<description>Pinging a server</description>

<xmllogger />
<artifactcleanup cleanUpMethod="KeepLastXBuilds" cleanUpValue="50" />


Updated by Kenneth Jensen almost 5 years ago

I forked the repo in github, cretaed a unit test and fixed the bug.

Updated by Ruben Willems almost 5 years ago

  • Status changed from New to Resolved
  • Assignee set to Ruben Willems
  • Target version set to 1.8.5

Updated by Ruben Willems almost 5 years ago

  • Status changed from Resolved to Closed

Updated by Emanuel Wlaschitz almost 4 years ago

I'm afraid this is not fixed. I still see those frequent rebuilds in a small-ish repository that uses a submodule (using ccservice.exe, Product version "Git hash : 7be2f10bc29d18e8ce5828c8af528886de75a482").

Source control block looks like this (copied from the Project Configuration at the dashboard):

  <sourcecontrol type="git">
    <dynamicValues />
    <executable>C:\Program Files (x86)\Git\cmd\git.exe</executable>
    <issueUrlBuilder type="regexIssueTracker">
    <tagCommitMessage>CCNet Build {0}</tagCommitMessage>
    <timeout units="hours">1</timeout>

The repository has a simple submodule (.gitmodules):

[submodule "inc"]
    path = inc
    url = git@srv:scripts/Shared

At every $intervalTrigger.seconds, i see a new build on the server.

Also available in: Atom PDF