Quiet Period Value ignored?

Hi,

I recently had a situation where it appeared that my 'Quiet Period' settings for triggering a build was ignored.


My build trigger is set as follows:

Build Trigger Parameters                           Description
VCS Trigger
Quiet                               period: 180 seconds (custom)



So it should be waiting for 3 minutes before attempting to trigger a build, however this was not the case.


My setup can be simplified as follows:
'Frequent Build Trigger' (Quiet period trigger as above)
---- Which is snapshot dependent on "Execute Tests Debug PC"
---- ---- Which is snapshot dependent on 'Runtime Compile All Libs Debug PC'

So every time the frequent build trigger is initiated, it'll then kick off compilation steps I require, in order to run the tests, so that the trigger config itself can be ran.


In this odd case, the 'Frequent Build Trigger' config is claiming that it ran a single time between the hours of '13 Sep 12 15:38' and '13 Sep 12 17:46' with a total of 27 changes present in that build (see below) - This is correct
jparker_TeamCity_SingleTrigger.png



But it's 'Runtime Compile All Libs Debug PC' dependency is being somehow triggered by it more than that, note there's still 27 changes, but spread over three builds. (see below) - This is incorrect.
jparker_TeamCity_MultiTrigger.png


Looking at that first incorrect build (#143) - It's claiming that the 'Frequent Build Trigger' started that build, but I can't determine how.... and clues?
jparker_TeamCity_IncorrectTrigger.png

Any assistance with this issue would be great, because it's currently meaning we're compiling many redundant builds.

Thanks.

11 comments
Comment actions Permalink

Apologies for the bump on this, but we've had to disable the VCS trigger and are now relying on manual and scheduled triggers instead.

Any information regarding potential flaws in my setup, things to check, or someone that's seen a similar thing would be great, as I've exhausted things I can think of.

Thanks,

0
Comment actions Permalink

What is shown as triggered by for builds #144 and #145 in 'Runtime Compile All Libs Debug PC' build configuration?

0
Comment actions Permalink

Hi Pavel, thanks for the response (apologies for creating a YouTrack issue for the same problem)

Build #144 - Triggered by:            Subversion; Build Triggers :: Frequent Build Trigger on 13 Sep 12 16:29
Build #145 - Triggered by:            Subversion; Build Triggers :: Frequent Build Trigger on 13 Sep 12 16:37


This is what appears to be so strange, as 'Frequent Build Trigger' states that it only trigger once between 15:38 and 17:46 (see the first image in original post).

Thanks,

0
Comment actions Permalink

I have only one explanation for now. When build chain is added to the queue TeamCity tries to find the same chain containing smaller number of changes and if there are no started builds in this chain TeamCity will replace it with the new one, and will move the new chain on the place of the old one in queue. If old chain contains started builds TeamCity will compare estimates, i.e. it will calculate whether the replacement will delay the result or not. If it does not delay result (top build of the chain), it will replace the old chain with new one.

So according to your screenshots this is what could happen. There was a chain in the queue triggered by VCS trigger, then other changes appeared in repository and another chain was added in the queue. In the first chain some builds already started, but still TeamCity decided it won't hurt to re-run these builds again, maybe because they are fast, or because estimates were not correct, or because of some bug...

So it's not like quiet period is ignored, in fact most lilely it works, and you can check it by taking a look at commits included into the "Runtime Compile All Libs Debug PC" builds. There should be delay for at least 3 minutes between the last commit included into the previous build and the first commit included into the next build. If delay is there, then most likely what we see here is the effect of builds merge operation.

0
Comment actions Permalink

Hi again Pavel,

Thanks for the helpful answer (I've marked as such), and your explanation definitely explains some unexpected build triggering we've seen.
Although, this case unfortunately doesn't match your explanation, as the commits were purposely close together, to avoid triggering until a whole feature is merged back to our trunk.

I've attached an image of the contained changes in SVN, and the date of commit. Grouped by build number.

Unless I've misunderstood your response, we'd expect the time between revision 295023 and 295024 to be greater than the 3 minute quiet period value.
but in this case, the time between them is about 40 seconds (although interestingly, there's about 3 minutes between the first commit and the last in that build)

Thanks again for your assistance so far.

Message was edited by: Jim Parker - Attached image



Attachment(s):
teamCity_Forum_CommitFrequency.png
0
Comment actions Permalink

Could you please send me project-config.xml containing these configurations or attach it to the issue: http://youtrack.jetbrains.com/issue/TW-24342 ?

0
Comment actions Permalink

I've attached a zip to the linked issue, contains 2 projects, the triggers, and the build steps.

The actual setup is slightly more complicated than originally described, so I'll provide details of the actual chain.

'<build-type id="bt6" name="Frequent Build Trigger">' is triggered on 180 seconds of quiet time (you'll notice a few other triggers I've added since, these weren't present at the time)
That's snapshot dependent on '<build-type id="bt48" name="Frequent PC Build Trigger">'

Which is dependent on Frequent Builds <build-type id="bt47" name="Runtime Execute Smoke Tests Debug DX9"> (formerly known as PC in the original report)
Dependent on <build-type id="bt46" name="Runtime Compile All Libs Debug DX9"> AND <build-type id="bt45" name="Deploy Smoke Packages DX9">

<build-type id="bt46" name="Runtime Compile All Libs Debug DX9"> is dependent on the last successful <build-type id="bt24" name="Deploy In-Built Resources">
<build-type id="bt45" name="Deploy Smoke Packages DX9"> is dependent on <build-type id="bt2" name="Compile BlitzTech Editor 32-bit"> and <build-type id="bt4" name="Compile BlitzTech Editor 64-bit">

<build-type id="bt24" name="Deploy In-Built Resources"> is specifically triggered by <build-type id="bt6" name="Frequent Build Trigger">


So, every 180 seconds of quiet time, we use snapshot dependencies to pull all of the above into the build queue, which ends up something like the following:
1 - <build-type id="bt2" name="Compile BlitzTech Editor 32-bit">
2 - <build-type id="bt4" name="Compile BlitzTech Editor 64-bit">
3 - <build-type id="bt45" name="Deploy Smoke Packages DX9">
4 - <build-type id="bt46" name="Runtime Compile All Libs Debug DX9">
5 - <build-type id="bt47" name="Runtime Execute Smoke Tests Debug DX9">
6 - <build-type id="bt24" name="Deploy In-Built Resources">
7 - <build-type id="bt48" name="Frequent PC Build Trigger">
8 - <build-type id="bt6" name="Frequent Build Trigger">

Hopefully that information helps.

0
Comment actions Permalink

Could you please execute the following SQL statements against the TeamCity database:

select * from vcs_history where display_version = '295023';
select * from vcs_history where display_version = '295024';

select * from vcs_history where display_version = '295035';
select * from vcs_history where display_version = '295036';

and attach here results?

0
Comment actions Permalink

I've added each SQL query saved as html into the zip.
Apologies for saving them as html print previews, it was the simplest way I could retain the table information.

Thanks for continuing to assist with this.



Attachment(s):
SQL Queries.zip
0
Comment actions Permalink

Jim, it seems the cause of the issue is clear now. As a workaround please try to set quiet period twice as big as checking for changes interval in VCS roots of "Frequent Build Trigger" configuration.

0
Comment actions Permalink

Ah, I see, so because my checking interval for my VCS was higher than the default 60 seconds (it appears I set it to 180 secs too :( ), TeamCity thought that no changes had occurred and so triggered the build? although if it checked more frequently, it would have spotted those changes and therefore waited?

I'll give this a go, but it sounds like that'll resolve it perfectly, so I'll go ahead and mark this question as 'answered'.

Thanks so much for looking into this issue, I'm glad it ended up being user error.

0

Please sign in to leave a comment.