Snapshot dependency collected from default branch instead of selected branch for dependent build when revisions are different
Hello,
I have 2 build configs, one that compiles my application (A) and one that uploads it to Octopus Deploy (B). I have a snapshot and artifact dependency configured to collect my compiled application artifact from config A, and the dependency is set to use the artifact from the same chain.
I have a feature branch that has run through config A, and i want to deploy it with config B. When I run B, it will instead get its artifact from a more recent (in time, not commits) build from A that has occurred on the default branch (master). This default branch does not yet have any of the commits from my feature branch, and my feature is ahead of master by several commits.
I have read about the possibility of replacing a dependency with one from the default branch "if it is suitable by revisions", but i cannot understand how that could be the case here, when my desired branch is many commits ahead of the default branch. https://teamcity-support.jetbrains.com/hc/en-us/community/posts/205409690-Teamcity-not-respecting-branches-in-dependent-builds
Any help you can offer on the subject would be greatly appreciated. Thanks in advance for your time and help.
I am using Teamcity 10.0.3 (build 42434)
Edit: testing this more, i can see that my dependency used is always the latest from the default branch, or my desired branch only if it is a more recent build than default.
Please sign in to leave a comment.
Hi Drew,
how are you running B? There are several possibilities for what you are experiencing and for the solutions:
I assume that you have your VCS Trigger on A, as not every build is published, and that then you run manually B. This creates the problem that B is run on the default branch, and thus pulls the last successful build from A, but if you have branches on B, the branch will also be used on A, and default runs pull the default branch.
In this scenario, you can:
-Instead of just click on "Run", click on the ellipsis (…) next to it, then select exactly which dependencies you want to apply.
-Instead of running B, go to the exact build you want to publish, then select in the "Actions" menu the "Promote" action. It will start the build chain with B for publishing using that exact build results.
Another option is to have the VCS Trigger on B, and thus every commit will be built, and, when the conditions are met (successful, etc), published. In this scenario, the result commit that is being built should automatically be published, but depending on your configuration, the revision pulled for the build might be different. We would need to know more details about what is going on to be able to debug here.
If this doesn't help, please post screenshots of how your dependencies are configured, then mention exactly where the triggers are and/or how you are running B.
Hi Denis,
Thanks for getting back to me. You are correct in that a VCS trigger is set for A, and anywhere from 5 minutes to 3 days later, B will be manually started. I have configured the same VCS settings on both A and B, so my branch selector on the dashboard should encompass all the build configurations.
Since I first posted this issue, I have tried breaking out some of my steps into additional configurations (A to compile, B now uploads to octopus and a new config C, handles the deploy of the package from Octopus). This setup now uses a successful finished build on A to trigger B. Any developer can then at a later time, trigger C manually.
This appears to be working for me now as the finished build trigger paired with the pre-existing snapshot and artifact dependencies look to be pairing the artifacts and branches that I would expect, and the new config C uses the build number of its snapshot dependency and not the artifact itself. I'm not 100% sure i have actually solved anything, or just masked it with a process that makes the scenario less likely to occur, but it has allowed me to proceed for now regardless. I appreciate your input on the subject. Thanks again.