Snapshot dependency not triggering correctly
I have a simple "test => compile" dependency chain. The "test" configuration is triggered by a Perforce submission, and has a snapshot dependency on "compile". The compile configuration always triggers correctly, but about 70% of the time, the dependency chain shows that the "test" configuration is "Not triggered" and I have to manually trigger it. What would cause this?
Please sign in to leave a comment.
Rebooting the TeamCity server helped for a short time, but it's getting back into this state again.
Hi Samb,
that's a pretty strange scenario, could you please post screenshots of the trigger and snapshot dependency configurations? Which version are you running? Do you have the "Hide failed to start builds" checkbox active? It might be hiding failed to start builds and making you think they don't start at all?
We're running TeamCity Enterprise 10.0.5 (build 42677).
Here's the dependency
and here's one of the BCA jobs that shows the smoke test (which triggered the BCA job in the first place) not being triggered:
It looks like this might happen when the BCA job is queued up. When it's released from the queue, the original smoke test job is lost.
Thanks for the screenshots. That is definitely a strange issue. First, if you are using 10.0.5, I'd like to suggest setting up a test server of the new version and trying it out there. Version 10 is already out of support, so even if this was still reproducible in the newer ones, it would only get fixed there.
To provide some background, when a build is running and a new one of the same configuration is added to the queue with the exact same conditions (revision, parameters, etc), TeamCity will indeed optimize it by removing one of the two instances, but it should never remove the depending one. The dependency should be rearranged so that it points to the ongoing one, instead of the newly created -and optimized away- one.
Other than that, I would like to ask you for the teamcity-server.log file and teamcity-vcs.log for a timeframe where such a build was triggered, to see if we can find any traces in the logs for why this would happen. To do so, please use the submit a request button on top of the page.
I'm concerned about the confidentiality of posting logs to this forum. Is there something I should look for?
I realize you no longer support our version, and I am trying to convince management to upgrade to 2017.2.
I understand your concerns, but you don't need to worry: You can't upload logs to this forums. Using the submit a request button will send us a private ticket to our system and further communication will happen via email, our coworkers will have access to it, but only you and the people you put on CC should have access to it from outside.
Our issue tracker (https://youtrack.jetbrains.com/issues/TW) does have public access and allows for uploads, but you can explicitly select the visibility of the attachments to "jetbrains-team" so only we have access to them.
You can also upload it to our FTP and tell us here the name of the file you uploaded so we can just check it and still answer here. More info on that here: https://confluence.jetbrains.com/display/TCD10/Reporting+Issues#ReportingIssues-UploadingLargeDataArchives