I have a gated build "A" that produces an artifact as input to gated build "B"
I would like source code changes in build "A" to produce artifact that is checked in to source branch for build "B". Build "B" will use the gated shelveset and leverage the checked-in artifact from build "A"
When I configure the step check-in a file that is part of another gated build the check-in I get a GatedCheckinException
Microsoft.TeamFoundation.VersionControl.Client.GatedCheckinException: Your check-in has been placed into shelveset Gated_2017-06-26_01.40.32.2887;Build\be8b7d68-69c0-4469-918f-fc644107151a and submitted for validation by build definition ***
yet the other build is started and it indicates that it is using the shelveset from the build A.
I've never used this pattern before. I'd expect you to run into issues, as you are. I'd not recommend this pattern, unless you bypass the second gated checkin and just trigger the new build.
I have a gated build "A" that produces an artifact as input to gated build "B"
I would like source code changes in build "A" to produce artifact that is checked in to source branch for build "B". Build "B" will use the gated shelveset and leverage the checked-in artifact from build "A"
When I configure the step check-in a file that is part of another gated build the check-in I get a GatedCheckinException
Microsoft.TeamFoundation.VersionControl.Client.GatedCheckinException: Your check-in has been placed into shelveset Gated_2017-06-26_01.40.32.2887;Build\be8b7d68-69c0-4469-918f-fc644107151a and submitted for validation by build definition ***
yet the other build is started and it indicates that it is using the shelveset from the build A.
Is this supported?