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.
Please sign in to leave a comment.
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.
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".