False reports of incompatible configurations with snapshot dependencies and their parameters

My previous thread on this topic was incorrectly marked "Answered" and has been ignored ever sense, despite my bumps. Months have passed and two new versions have come out and this is still not fixed. So I'm making a new thread with up-to-date info.

TeamCity 8.0.6, two agents on one machine with different names and different install/work/temp directories. Perforce VCS roots.

Create a project named "Test Bed".

Create config named "Config Chain".
Add build parameter "BuildConfig" with value "Release"

Create two configs named "Build A" and "Build B".
Make both snapshot dependent on "Config Chain".
Add step "Step 1" with a simple script runner to all three, such as "Command Line" or "Python" (I'm using Python).
Add to the scripts of both an echo/print that references "%dep.TestBed_ConfigChain.BuildConfig%".
Note that in the build params section of these builds there are no errors.

Create a new config named "Build AB".
Make it snapshot dependend on "Build A" and "Build B".
Add step "Step 1" with a simple script runner and add an echo/print that references "%dep.TestBed_ConfigChain.BuildConfig%".

Go to the agents list and set both agents compatible configurations policy to "Run assigned configurations only".
Assign "Config Chain", "Build A", and "Build AB" to the first agent.
Assign "Build B" to the second agent.

On the second agent's "Compatible Configurations" page, you will see "Build B" listed as incompatible with the following error:
"Implicit requirements: dep.TestBed_ConfigChain.BuildConfig defined in Build step: Step 1"

Go to projects list and run "Build AB".
Note that all the builds run correctly and in order, including "Build B" running on the second agent that said it was incompatible.
Also note that the references to "%dep.TestBed_ConfigChain.BuildConfig%" correctly resolve the value  "Release" when echoed/printed in the logs.

2 comments
Comment actions Permalink

Hello,

Sorry for ignoring your thread. However, in this specific case I'd recommend to submit a bug report in our tracker. This way it has more chances to be fixed.

0
Comment actions Permalink

I've found a similar bug already on the tracker and added our experience and repro there.

http://youtrack.jetbrains.com/issues/TW-32528

0

Please sign in to leave a comment.