0

I have a problem with a build plan in a build chain that really bothers me.

I have a simple build chain A -> B where

  • A is very fast (less than a minute) - it basically does a database retrieval from a production system. There are no way to tell if the resulting artifact will be identical to the previous result before the processing has finished. Currently the build the time scheduled.
  • B is very slow (5-6 hours) - it combines the output from A plus a number of other sources into a large number of artifacts. Currently it has a snapshot dependency on A as well as a dependency on the other sources.

I would like to avoid running B unless needed - i.e. if any of the inputs to B has changed - but how do I do that?

I can fail/cancel A if it detects that the results are unchanged, but that will result in a "Snapshot dependency failure" for B, so if any other the other input sources to B does change it will not rebuild the results...

Are there any way to stop or abort the build of A so the build of B will not be triggered?

EDIT: I (might) have an idea: I could let A check in the resulting artifact in SCM - if it is different from the previous version - and let this drive the trigger of B - which already have a number of other sources in the SCM. It will not be part of the same build chain - as far as I can see - but it is the next best thing...

Tonny Madsen
  • 12,628
  • 4
  • 31
  • 70

2 Answers2

1

I don't think so. Build chains in TeamCity are static.

There are two possible workarounds

  1. Write a plug-in to handle this case. It would be a server-side plugin that kicks in on the buildTypeAddedToQueue(SQueuedBuild queuedBuild) event, when B is queued. It would do some looking around (comparing artifacts) and remove B from the queue immediately.
    • I believe this will behave as if B were queued and then de-queued by a user. I.e. it's not as hacky as it seems - removing builds from queue is a supported TC operation.
    • It may be more laborious than you'd wish...
  2. Handle this in B.
    • This is probably much simpler but I'm assuming you want to avoid this.

I think you'd ideally want to handle this within A so #2 is not an option. #1 comes close though of course it's a bit more involved.

sferencik
  • 3,144
  • 1
  • 24
  • 36
0

I guess it should skip the A rebuild and use the recent one if the new potential build of A is going to be identical to some of the recent ones. For example, requesting dependent build A with the same VCS revision and with the same settings shouldn't trigger the build again.

Alexander Goncharenko
  • 54
  • 5
  • Do you have something that may help to identify if your DB data has changed? Maybe a last update timestamp or just a random ID generated each time the data changes. If that's the case you may do the following. Remove the schedule trigger for your build A. Introduce another scheduled build which will check if the A should be rebuilt and trigger it accordingly. That way you will retain your scheduled updates but A will only be updated when it's really needed. But please be careful to check with TC's docs to ensure that the chain is configurable so to not rebuild A every time B is requested. – Alexander Goncharenko Sep 29 '15 at 19:10