No-op build just for dependency aggregation?

I am currently setting up a build chain with the dependency mechanism that works like this:


[Smoke-test-A]  [Smoke-test-B]
      |               |                

      +---------------+
             |
       [Do nothing job]
             |

      +---------------+        
      |               |
[Test-suite-X]  [Test-suite-Y]

Currently, my "Do nothing job" just contains a command-line runner that calls "ls".   Is this the recommended configuration if I want all of the "Test suite"s to run only if all of the "Smoke tests" succeed?  I could have many Smoke-tests and many Test-suites.  This seems like the easiest way to centrally manage that sort of dependency.  I don't mind having job that just calls "ls" but since there's no "No-Op" runner, I was wondering if this is a recommended approach or if there's an alternative.

2 comments
Comment actions Permalink

In fact in TeamCity 6.0 build configuration may not have build steps at all. Although we still need a better approach for dependencies agregation.

0
Comment actions Permalink

I see.  What I'm doing seems to work except that I cannot control the order in which dependencies are built.  I can't seem to avoid replicating dependency configuration throughout the individual component builds.

For instance:

[A1]  [A2]  [A3]
  |     |     |
  +-----+-----+
        |     
   [Aggregator] [Install]
        |           |

        +-----+-----+
              |
         [System-Test]

When "System-Test" is started, I'd like "Install" to always run before any of the "A" series builds are executed.

I can solve the problem by making "Install" a dependency of each of the "A" builds, but that's not optimal to me since it's harder to manage due to replication and not as clear to someone inspecting the "System-Test" job dependencies.

I could also solve the problem by using build steps instead of build configurations  for "Aggregator" and "Install", but I would prefer to have independently configurable jobs for those.  Perhaps a build-step that simply triggered a different build configuration would work?  System-Test would then just have two additional, initial build steps: "Start Install" and "Start Aggregator".

0

Please sign in to leave a comment.