Snapshot dependency fail and re-triggering build

Is there a way to trigger a build after a snapshot dependancy failure has been fixed?

For example, we have 2 build configurations, build X and Y.   Build Y has a snapshot dependency on X, but build X just failed.  Is there a way to automatically re-trigger build Y when build X is succesful?


Comment actions Permalink

Perhaps I misunderstand the question - but assuming you're meaning Maven snapshots, I think this would normally happen automagically as a result of your "mvn deploy" updating build X's snapshot artifact in a repository that TeamCity's Snapshot Depeendency Trigger is watching for build Y?

Comment actions Permalink

Here's the situation we have:
We have 2 builds, one for code and one for content.  The content build has a dependency on the code build.

If we have 2 vcs submits, one for code and one for content at the same time, TeamCity will kick off a code build and queue up a content build (because the content build depends on the code).
The problem is if the code build fails, the content build will never be triggered.  Even if we fix the code build and submit the fix, it will only trigger the code build and not the content.  We want to make the content build also re-trigger if it's previously failed dependancy has now been fixed.  And we obviously don't want to force a code build to always trigger a content build either.  Is there any way to do this?


Comment actions Permalink

Yes, in part that's why I ask whether you're using Maven. :)

One way to handle this, which we use with Maven builds is:

Code Build: Has VCS trigger. On successful compile+test run, it does a mvn:deploy of CODE-SNAPSHOT artifacts.
Content Build: Has VCS trigger + "Maven Snapshot Dependencies trigger" in TeamCity. Has a Maven dependency on CODE-SNAPSHOT.

This way, if you commit to both at the same time (and say the code build fails).

Code Build runs because of VCS trigger, fails, does not publish artifact.
Content Build runs because of VCS trigger, possibly fails because it's missing something from code build that has changed (if there is a compatibility requirement between them). This failure is fine to me, it represents that the content and code are out of sync and you'd generally want to know about it.

Code Build issue is fixed/committed to VCS, triggered again. This time it succeeds so publishes Maven artifact to CODE-SNAPSHOT in remote repository.
TeamCity notices dependency SNAPSHOT artifact has changed in repository, so triggers Content Build.
Content Build pulls down Maven dependency, so now runs and passes.

Even if you don't use Maven, you can achieve the same thing with a "Finish Build trigger" with option to "trigger on successful builds only"; it just depends if you model this dependency within Maven, or whether you use some other style of build. This is why I don't really understand why you say "it will only trigger the code build and not the content." - the triggering is within your control in TeamCity so you can model such dependencies either implicitly through Maven, or explicitly through Finish Build Triggers for non-Maven environments. Once you've fixed the code build, if dependencies are modelled correctly, it can be made to kick off the content build?

Why do you say "we obviously don't want to force a code build to always trigger a content build either"? This isn't obvious to me - surely if there is a dependency between them, when you change something in the code you want to re-run the content build to check none of the changes have affected this "dependent" build?


Please sign in to leave a comment.