1

When I check-in a file, the TFS CI trigger waits very little and starts the build. The problem is that I may have 10-30 files to check-in, and I would like the TFS to wait at least 5 minutes after my last file checked in before it starts a new CI build. In Cruise-Control I had a "modificationDelaySeconds" property where I could set the minimum amount of seconds to wait after the last check-in. How do I do this in TFS (2012)?

nonstopcoding
  • 729
  • 11
  • 21

1 Answers1

0

The closest alternative in TFS is to define Rolling Builds (also known as Batched-CI-builds).

Change the build trigger from Continuous Integration to Rolling Builds. This way, the build waits till the last build has finished; you can also configure that you do not want to build more often than every 5 minutes.

Markus
  • 20,838
  • 4
  • 31
  • 55
  • 1
    I have tried that. Unfortunately this does not solve the problem. As soon I check-in (assuming that the last build was longer ago than the "Build no more often than...") the build is triggered. – nonstopcoding Mar 10 '14 at 13:04
  • 1
    @DarkAPI: Why do you check in file-by-file? Can't you check them in as a single changeset? If you cannot do otherwise, you can try to use the `*** NO_CI ***` suffix as a check in comment for all but the last changeset, so that the CI build is omitted: http://stackoverflow.com/questions/3829305/what-does-no-ci-stand-for – Markus Mar 10 '14 at 15:11
  • The reason I check-in file by file is so that I can enter a comment for each checked-in file. This is the convention we have at the company so that when looking through Visual Source Safe (which we just upgraded to TFS a week ago, hence the question) we can see a history for modifications for each individual file. I'm assuming that in TFS is kind of the same (I maybe wrong) and if I just leave 1 comment for 20 files, than whoever looks through history will not have a clear idea WHY a specific the file was modified unless he/she looks at the code of course. – nonstopcoding Mar 10 '14 at 15:30
  • 2
    @DarkAPI: If you check in file by file, you loose one of the biggest advantages over SourceSafe: atomic check-ins of a set of files in a ChangeSet. Each changeset is a consistent set of changes. If you check in file by file, the state of the TFS repository is invalid in between (maybe this is the reason for your initial question on how to avoid the CI build). I understand that the finer-grained history is a reason, nevertheless I'd recommend to rethink whether you want to continue this approach. You'd also be much faster if you can check in all files at once. – Markus Mar 10 '14 at 17:04
  • 1
    Thanks for the info. I agree that it would be much faster to check-in all the files at once. I'll try to convince my coworkers to take this approach. – nonstopcoding Mar 10 '14 at 17:35