J'utilise la cible suivante dans mon TFSBuild.proj:
Injecter les nouvelles cibles dans le processus de construction. Nous déclenchons ne dépend builds si a été créé avec succès une « baisse »:
<PropertyGroup>
<DropBuildDependsOn>
$(DropBuildDependsOn);
CreateDependentBuildItemGroup;
TriggerDependentBuilds;
</DropBuildDependsOn>
</PropertyGroup>
Créer une ItemGroup qui contient une liste de la personne à charge construit nous voulons déclencher (Inclure attribut liste le nom de la construction dépendante tel qu'il apparaît dans l'explorateur de construction - dans mon cas ci-dessous, la construction dépendante est appelée "Intégration"). Dans notre processus de construction, nous voulons parfois déclencher plus d'une construction, et nous voulons pointer la prochaine construction sur les binaires qui ont été produits par la construction actuelle (dans cet exemple, je veux exécuter des tests d'intégration sur les binaires produits). Notez le hack pour contourner les espaces dans les noms de configuration - par exemple "Any CPU" provoquera un problème dans les arguments MsBuild. En utilisant ce format, nous pouvons avoir des arguments MSBuild personnalisés par construction dépendante.
<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>
Maintenant, déclenchez les générations. Notez que nous utilisons un GetOption personnalisé: nous voulons nous assurer que les builds dépendants utilisent le même changeset que la build actuelle utilisée - nous ne pouvons pas utiliser Latest, car quelqu'un a peut-être archivé entre-temps - donc nous voulons que tous les builds dépendants notre "chaîne" à tous être basée sur le même changeset. La commande réelle est dans l'Exec, et la tâche BuildStep est de s'assurer que nous signalons le succès (ou l'échec) de l'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:"%(DependentBuild.MsBuildArgs)"">
<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>
J'espère que cela ...
Pouvez-vous poster le dossier complet? (et le modèle)? Merci –
Désolé - est passé de ce travail et n'a plus accès. Vraiment, il devrait y avoir assez dans le ci-dessus tho .... –
Pas de problème. Je l'ai compris en utilisant le modèle de définition de construction. –