Wir verwenden TeamCity. Ich habe einen BuildAgent in einer Windows-Box installiert, wo er als Dienst ausgeführt wird. Anstatt es unter dem lokalen Systemkonto auszuführen, habe ich beschlossen, es als dedizierten Benutzer auszuführen. Diese Maschine wurde verwendet, um unsere Lösungen in der Vergangenheit zu bauen, und alle notwendigen Werkzeuge sind bereits installiert und von diesem Benutzer zugänglich.BuildAgent-Zugriff auf xcopy und attrib bei Ausführung als Dienst
Die meisten der Gebäude und Tests funktioniert gut. Aber ich habe einige Vor- und Postbuild-Schritte, die administrative Arbeit erledigen. Diese Schritte verwenden externe Befehle wie attrib und xcopy (wie üblich in System32). Diese können vom BuildAgent nicht ausgeführt werden, wenn sie mit dem dedizierten Benutzer gestartet wurden. Wenn ich diesen Befehlen den vollständigen Pfad zu System32 hinzufüge, funktionieren sie auch gut. Es scheint also ein Umweltproblem zu sein.
Beim Starten mit dem lokalen Systemkonto werden diese Schritte wie erwartet ausgeführt. (Es gibt andere Gründe, das lokale Systemkonto nicht zu verwenden, daher ist das leider keine Lösung.)
Die Ausweichlösung, die den BuildAgent von der Konsole aus ausführt, funktioniert ebenfalls gut. Da es jedoch auch möglich ist, den BuildAgent als Dienst auszuführen, wenn das lokale Systemkonto verwendet wird, suche ich nach einer Möglichkeit, den dedizierten Benutzer (Rechte oder Umgebung) zu ändern, damit der BuildAgent als Dienst ausgeführt werden kann.
Was fehlt mir?