Die zentralen Builds im Team Foundation Server legen ihr Ergebnis in Form der Binaries, Log-Dateien und Ähnlichem in einer dedizierten Freigabe ab. Welche Freigabe im Netzwerk verwendet werden soll, lässt sich selbstredend konfigurieren. Allerdings ist das mit Einschränkungen verbunden. Wie man diese Einschränkungen überwinden kann, soll dieser Artikel zeigen.
Intern wird das Zielverzeichnis nämlich aus verschiedenen Teilen zusammengebaut. Und zwar aus der Build-Property “DropLocation” und der Buildnummer (Property “BuildNumber”). Die Logik dahinter ist in der zentralen Microsoft.TeamFoundation.Build.targets-Datei auf dem Buildserver hinterlegt und zwar im Target “InitializeEndToEndIteration” zu Beginn des Builds. Der Teil des Skripts liest sich wie folgt:
<!– Initialize the build for EndToEndIteration –>
<Target Name=”InitializeEndToEndIteration” >
[…]
<!– Update the build number and drop location in the database.
This task will also create the drop directory
and grant the service account full rights on it.
–>
<UpdateBuildNumberDropLocation
TeamFoundationServerUrl=”$(TeamFoundationServerUrl)”
BuildUri=”$(BuildUri)”
BuildNumber=”$(BuildNumber)”
DropLocation=”$(DropLocation)\$(BuildNumber)” />
[…]
</Target>
Dieses Stückchen Skript sorgt dafür, das im Buildbericht (im Build Explorer oder im Browser) die Links zum Buildergebnisverzeichnis richtig dargestellt werden:
Für den Standardfall sind diese Pfade wie zum Beispiel \\tfs\Buildresult\Calculator.Demo\DailyBuild\DailyBuild_20081119.1 sicher ausreichend. In einigen Fällen ist es aber notwendig andere Verzeichnisnamen zu verwenden, die eben nicht die Buildnummer enthalten. Ein möglicher Weg das zu verhindern wäre, die zentrale targets-Datei zu ändern. Das sollte aber vermieden werden, da solche Änderungen bei Updates, wie dem Team Foundation Server SP 1 auf dem Buildserver überschrieben werden könnten. Zudem muss die Änderung in allen relevanten Buildservern erfolgen und kann nicht pro Build angepasst werden.
Als Ausweg empfiehlt es sich, den Eintrag in der Datenbank erneut zu überschreiben. Und zwar unmittelbar nach dem originalem Eintrag, also im Target “BeforeInitializeWorkspace”. Hier kann ich dann den Verweis auf die “DropLocation” beliebig anpassen:
<!– Overwrite the build droplocation link –>
<Target Name=”BeforeInitializeWorkspace” >
[…]
<!– Update the build number and drop location in the database.
This task will also create the drop directory
and grant the service account full rights on it.
–>
<UpdateBuildNumberDropLocation
TeamFoundationServerUrl=”$(TeamFoundationServerUrl)”
BuildUri=”$(BuildUri)”
BuildNumber=”$(BuildNumber)”
DropLocation=”\\server\beliebigerPfad“ />
[…]
</Target>
Dieses Skriptstück wird z.B. in die buildspezifische TFSBuild.proj eingefügt und sorgt für ein Überschreiben des Links im Buildbericht. Zudem müssen die Buildergebnisse noch an die neu definierte Stelle kopiert werden, da auch hier die Buildnummer per Default mit in den Pfad eingebaut wird. Das kann dann im Target “AfterDropBuild” passieren.