Qn: Execute build configuration without triggering dependancies or downstream builds
Hello,
We have some lengthy build configuration chains, where A depends upon B and C, and the completion of A triggers the build for D and E.
Sometimes to test something, I just want to run A. I don't want B and C executed, nor do I want D or E executed.
Is there a way to achieve this without modifying the configuration? I know I can disable the trigger, and delete the dependencies rules. But that seems really heavy handed to test build step A. Especially since, with an interrupt driven work environment, it's easy to get called away on to something else while in the middle of the "temporary" test modification that becomes permanent because it's forgotten.
Teach me. What's the best way to do this?
Please sign in to leave a comment.
Hi John,
Why not simply duplicate the build configuration, call the second one "Test_whatever" and then simply remove the dependencies/triggers from the test one? You can extract a template first and make both inherit from it so changes in the template are directly applied to both.
Hello,
That's what I do now. But the response from the teams using the tools is that it's too much clicking around, navigating from one project to another to do deployment debug tests, or to recover from a deployment failure caused by an unresponsive step.
For example, they want one click to do as much as possible in ascenario, but if a failure is encountered they want discrete manual control.
Click the button and applications A1, A2 and A3 are shutdown, then service S1 and S2 are shutdown. All done as separate build configs.
They verify some things.
Click the button and software is deployed to A1, A2, A3, S1 and S2.
Wait for DBAs to do their magic
Click the next button and services S1 and S2 are started then applications A1, A2 and A3.
The challenge is... if there is a failure in one of the build steps they want to start going through one by one manually without automatically triggering the next step. Other members will be adjusting something, like ensuring the correct deployment permissions were rolled out on servers X, Y and Z, or that we don't have a connectivity issue to server W, etc.
The users I'm preparing this for don't want to have to navigate to another screen. Even though it's the same build configuration -- the old screen showed failed (red) and the new one will be unrelated (might be green, might be red, depends upon the last time it was executed.) You and I know it's a template and works the same -- to them it's different.
For build steps, we have this request in our tracker: https://youtrack.jetbrains.com/issue/TW-17939
For full build configurations, while I see your point, it's harder to make sense of it. An artifact dependency implies that the build needs that artifact to be able to succeed. For optional artifacts, please see here: https://youtrack.jetbrains.com/issue/TW-19132
A snapshot dependency is used to require order, which in turn also implies a deep connection between the two configurations. It would be expected that without that dependency being run (or having a successful "suitable" run), the new one should fail (or whatever is configured on the dependency condition).
If you really feel this functionality would be helpful (I'm not saying it wouldn't but please consider its impact), please feel free to send us a feature request here: https://youtrack.jetbrains.com/issues/TW
The more details you give about the scenario, the easier it would be to consider it for implementation.
Hello Denis,
Thank you for your response and patience. Your response helps me understand the situation better, and reminded me that our company seems to be using TeamCity for activities it was not intended for.
The scenario that the previous developer left for us was to assist with the site deployments. During the deployment sites and services have to be shut down in a specific order. The non-technical deployment operator (audit requirement), executes the stop all TC build rule.
Technically this isn't a build. It's using the windows remote management ability combined with the CLI build step option to shutdown the remote sites and services. These actions do not have build artifacts, etc. The only real dependency is that step 1 should be completed before step 2, and then step 3, etc.
However, when things become problematic, the desire is to override, the order. And explicitly control a single step without triggering anymore.
Overall, I believe we are using TeamCity in a way that it wasn't intended for -- since it's not a build. Or perhaps you can teach me that correct way that this should have been implemented?
Thank you for your help.
John.
Hi John,
While the details are indeed different, I don't think it's that different an scenario. Actually, we are just taking it to an extra level of isolation. In your scenario, we would consider that the step that is normally in the middle of a chain is slightly different from the one you can run in isolation. It seems the difference is a bit more in workflow that in ability to do something.
The idea would be, if some part of a "build" (or deployment) fails, it should be fixed by whoever is doing that part locally, then once that part is fixed, you would test that part in isolation in TC, then once it works you would run it through the full chain.
Under this workflow, running something in isolation is slightly different to running it as part of a larger process, and probably should be run independently (a.k.a. different build configuration), which would also be able to tell you whether the issue is in the isolated part or when it is part of the chain.
There is another possible workaround for the issue. And with some extra work, it might even include a "one click solution". Build configurations, and that includes dependencies, can be modified through the REST API. You can prepare a script that runs a REST API call that modifies a specific build configuration to drop its dependencies, then pushes a build of that same build configuration, waits until the build is started, then restores the previous state of the build configuration. You could create a plugin that modifies the Web UI to add a button that would do that "automatically", but this would definitely require some tinkering. Info on how to modify the Web UI here: https://confluence.jetbrains.com/display/TCD10/Web+UI+Extensions