Trigger build, gdy inny zakończył się pomyślnie w TFS 2008

Question

Jest to funkcja, z której jestem przyzwyczajony od TeamCity - mógłbym określić, że pewna konfiguracja kompilacji zostanie wywołana sukcesem innej konfiguracji kompilacji.

Mogę nawet przekazać wyniki jednej wersji do drugiej - ale być może to za dużo.

Poszukuję podobnej funkcjonalności w TFS2008, czy istnieje sposób ustawienia wyzwalacza w konfiguracji kompilacji, który rozpocznie się po pomyślnym zakończeniu innego?

Answer 1

używam następujący cel w moim TFSBuild.proj:

wstrzyknąć nowe cele w procesie budowania. Mamy tylko wywołać zależne buduje czy „drop” został pomyślnie utworzony:

<PropertyGroup> 
    <DropBuildDependsOn> 
     $(DropBuildDependsOn); 
     CreateDependentBuildItemGroup; 
     TriggerDependentBuilds; 
    </DropBuildDependsOn> 
</PropertyGroup> 

Tworzenie ItemGroup który zawiera listę utrzymaniu buduje chcemy wywołać (atrybut Zawierać będzie zawierać nazwę kompilacji zależnej jak widać w eksploratorze kompilacji - w moim przypadku poniżej zależna kompilacja nazywa się "Integracja"). W naszym procesie budowania czasami chcemy wywołać więcej niż jedną kompilację, a my chcemy wskazać następną kompilację w plikach binarnych, które zostały utworzone przez bieżącą kompilację (w tym przykładzie chcę przeprowadzić testy integracji z utworzonymi plikami binarnymi). Zwróć uwagę na hack, aby ominąć spacje w nazwach konfiguracji - np. "Any CPU" spowoduje problem w argumencie MsBuild. Korzystając z tego formatu, możemy mieć niestandardowe argumenty MSBuild na zależną kompilację.

<Target Name="CreateDependentBuildItemGroup"> 
    <ItemGroup> 
     <DependentBuild Include="Integration"> 
      <!--Using 8dot3 format for "Mixed Platforms" as it's tricky (impossible?) to pass a space char within /msbuildarguments of tfsbuild--> 
      <MsBuildArgs>/p:CallingBuildDropFolder=$(DropLocation)\$(BuildNumber)\Mixedp~1\Ship;CiSmallBuildNumber=$(CiSmallBuildNumber);BuildNumberPostFix=$(BuildNumberPostFix)</MsBuildArgs> 
      <PriorityArg>/priority:AboveNormal</PriorityArg> 
     </DependentBuild> 
    </ItemGroup>  
</Target> 

Teraz wyzwalaj kompilacje. Zwróć uwagę, że używamy niestandardowej metody GetOption: chcemy się upewnić, że zależne kompilacje używają tego samego zestawu zmian, którego użyto w obecnej wersji - nie możemy użyć opcji Ostatnie, bo ktoś mógł się w międzyczasie sprawdzić - więc chcemy, aby wszystkie zależne kompilacje były nasz "łańcuch" dla wszystkich opiera się na tym samym zestawie zmian. Faktyczne polecenie znajduje się wewnątrz Exec, a rzeczy BuildStep mają na celu sprawdzenie sukcesu (lub niepowodzenia) Exec.

<Target Name="TriggerDependentBuilds" 
     Condition=" '$(CompilationStatus)' == 'Succeeded' "> 
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
       BuildUri="$(BuildUri)" 
       Name="TriggerStep" 
       Message="Triggering Dependent Builds"> 
     <Output TaskParameter="Id" 
       PropertyName="TriggerStepId" /> 
    </BuildStep> 

    <PropertyGroup> 
     <TriggerBuildCommandBase>TfsBuild start $(TeamFoundationServerUrl) $(TeamProject)</TriggerBuildCommandBase> 
    </PropertyGroup> 

    <Exec 
     ContinueOnError="true" 
     WorkingDirectory="C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE" 
     Command="$(TriggerBuildCommandBase) %(DependentBuild.Identity) /queue /getOption:Custom /customGetVersion:$(GetVersion) %(DependentBuild.PriorityArg) /msbuildarguments:&quot;%(DependentBuild.MsBuildArgs)&quot;"> 
     <Output TaskParameter="ExitCode" 
       ItemName="TfsBuildResult"/> 
    </Exec> 

    <BuildStep Condition="'@(TfsBuildResult)'=='0'" 
       TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
       BuildUri="$(BuildUri)" 
       Id="$(TriggerStepId)" 
       Status="Succeeded" /> 
    <BuildStep Condition="'@(TfsBuildResult)'!='0'" 
       TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
       BuildUri="$(BuildUri)" 
       Id="$(TriggerStepId)" 
       Status="Failed" /> 
</Target> 

Mam nadzieję, że pomaga ...