VCS Trigger Usage question

I was hoping to get some clarity on the matter.
Noting that VCS roots by default check for changes every 180 seconds.
A vcs trigger will trigger if there are changes detected, and thus will trigger every 3 minutes with all the changes that happened in the past 3 minutes in a single item?
For a special build configuration I am hoping to expand that grouping of changes from 3 minutes to say 30 minutes, but I don't want to change the "check for changes" delay for the vcs root as this will affect every build configuration that uses the root.

Another thing to note: I don't think I can use the "schedule trigger" trigger type as we are dependent on the snapshot depency for changes - and schedule trigger doesn't support this (Unless I am mistaken?)

Does anyone do something in a similar fashion or have any recommendations for my problem?

Cheers,

Mark.

15 comments
Comment actions Permalink

You can quite period (http://confluence.jetbrains.com/display/TCD8/Configuring+VCS+Triggers#ConfiguringVCSTriggers-quietPeriod) in VCS trigger settings. After VCS trigger realizes that there's a change to make a build against, it would wait for a quite period for further changes and then queue a build

0
Comment actions Permalink

From my understand of quiet period, if I set this to a decent time period, it could potentially stop the build from triggering all day, until everyone in the team stops commiting?

0
Comment actions Permalink

Quite period starts, when TC identifies a first commit after previous build is triggered. If developer commits at 9:00AM and quite period is 30 minutes, then the build would be triggered at 9:30AM and it would include all commits made between 9:00 and 9:30

0
Comment actions Permalink

From the documentation I see a different behavior than in your example.

From the documentation: "If new VCS change is detected in the Build Configuration within the period, the period starts over from the new change detection time."

Does this mean that the next check of the VCS change ist later and not that the quiet period starts again?

0
Comment actions Permalink

You're right, quite period is not what I said. It is designed to not break the atomic changes in several VCS roots.

For your initial question, what is the purpose to extend the "check for changes" timeout?

0
Comment actions Permalink

I thought: the vcs trigger would be depend on the 'checking for changes' period, and thus by increasing the period it would mean changes are only noticed say every 30 minutes in the trigger.

0
Comment actions Permalink

That's correct. VCS trigger relies on 'checking for changes' functionality. And increasing checking interval would result in less frequent builds.

0
Comment actions Permalink

Hi,

I think in this case you can use "Schedule trigger". Snapshot dependency logic works for all kind of triggers. If you configure schedule trigger for the last build in the build chain, all the builds it depends on will be triggered too.
Also if some of the build configurations from build chain already have started builds with matching changes ("suitable builds") and you don't want to run them one more time, you can use "Do not run new build if there is a suitable one" snapshot dependency option. Corresponding builds will be then silently removed.

0
Comment actions Permalink

I am unsure of what you mean by: "schedule trigger for the last build in the build chain"? Are you referring to using the "last successful build" in our artifact dependencies? Currently we are using "build from the same chain" for our dependencies.

0
Comment actions Permalink

For example, you have a chain C->B->A, where A snaphot-depends on B and B from C. When build A (the last build in the chain) is triggered (for example by schedule trigger every 30 mins) TeamCity resolves the whole build chain and queues all builds - A, B and C.
When the builds are added to the queue, TeamCity starts checking for changes in the entire build chain and synchronizes them - all builds have to start with the same sources snapshot.
Once build C has successfully finished, build B starts, and so on. If build C failed, TeamCity won't further execute builds from the chain.
If both snapshot and artifact dependency are configured, and the Build from the same chain option is selected in the artifact dependency settings, TeamCity ensures that artifacts are downloaded from the same-sources build. I think this one is suitable in your case.

0
Comment actions Permalink

I agree, that is how we want it to work, and how we first understood it to work, but for some reason in our instance it isn't triggering. I figured it was because the last build configuration in the chain has no vcs roots, and "Scheduled trigger" does not have checkbox for: "Trigger on changes in snapshot dependencies" like what "VCS Trigger" does. I imagine this checkbox was not included because it is not handled? Unless there could be another reason why ours isn't triggering?

0
Comment actions Permalink

"Scheduled trigger" just run a build at a specific time, it does not check for changes as "VCS trigger".
Can you please describe your configuration in more details (better with screenshots), how do you expect it should work and how does it work now?

0
Comment actions Permalink

We have a build which is the only build that has vcs roots, all other build configurations just run from the artifacts of this first build.
The snapshot dependency setup as illustrated in snapshotdependency.png image attached.
The artifact dependency setup as illustrated in snapshotdependency.png image attached.
The dependencies seem fine- running the build up the chain triggers the ones below it and collects the correct artifacts.
The first build which contains the vcs roots is detecting changes and running as expected, but the builds that depend on it are not recognising these as changes. We have had builds not trigger for over a week with this setup.



Attachment(s):
SnapshotDependency.PNG
ScheduleTrigger.PNG
ArtifactDependency.PNG
0
Comment actions Permalink

For which build configurations did you configure Scheduled trigger?
Dependencies in Teamcity work in the following way. If the last build in the chain is triggered, the whole build chain will be added to the build queue, but not vice versa! If the first build is triggered (the build with VCS root in your case), it doesn't affect anyhow the build chain. There are good examples here - http://confluence.jetbrains.com/display/TCD8/Build+Dependencies+Setup.

0
Comment actions Permalink

Both builds have scheduled triggers, the only difference being the compile build is scheduled to be more frequent.

0

Please sign in to leave a comment.