views:

342

answers:

2

Hi,

My setup: One project with two build configs ("ci" and "reset dbs")

  • the "ci" is just a regular ci build of the project

  • the "reset dbs" uses the same VCS but only triggers builds in the "common\database" folder (runs reset of the databases required for the tests) (trigger pattern: +:Common/Database/**)

Now - I would that when I check stuff into the "database" folder - the "reset dbs" build is always run BEFORE the regular "ci" build.

What I've done now is set the quiet period of the "ci" build to the same as the poll interval for the VCS - that SHOULD give me that the "reset dbs" always runs first right?

Seems to be working so far (a couple of test commits) - but I want it to totally correct.

Is there a better way to do this?

I see one other way of doing it which would be to copy the "ci" config and have one called "ci after reset" that is triggered after the reset build. And then let the regular "ci" exclude the "database" folder. Feels like a hack.

Thank you!

Update: The whole idea is to not have to run the "reset dbs" on every commit, but just when needed - and in that case it has to run before the "ci" build. Thanks for the responses so far!

+1  A: 

You could configure the "reset dbs" config to be triggered by a checkin (the default), and have the "ci" config triggered by the completion of the "reset dbs" config (called a "dependency" trigger).

Philippe Leybaert
Thanks, but I would like for the "reset" build to not always run, but the "ci" should always run. (see the update in my question)
andyhammar
+1  A: 

I don't know if it solves it, but theres a tab called dependencies under Build triggering. There you can select a build that must be run before the current build.

Kenny Eliasson