Jenkins und Netzlaufwerke

[himitsu]

Der Jenkins läuft nicht zufällig in einem anderen Nutzeraccount, als wie du normal im Windows eingeloggt bist?

Wenn nicht, dann sieht er eventuell ein "virtuelles" Laufverk nicht, weil es vermutlich nur in deinem aktuellen Nuteraccount eingerichtet ist, z.B. beim SUBST.

[Harry Stahl]

Nein, ist der gleiche Benutzer-Account. Ich nutze Virtualbox als VM, unter Linux.

[Lemmy]

kenne ich auch so, weiß aber keinen Grund dafür, ich greife halt per unc Pfad auf die Netzlaufwerke zu.

[jaenicke]

Das Problem sind vermutlich die verschiedenen Benutzertoken, selbst wenn man den Dienst unter dem gleichen Konto startet.

Eine simple Lösung ist, das Netzlaufwerk auch im Dienstkontext unter dem gewünschten Nutzer zu verbinden. Das kann man ganz einfach machen, indem man den Befehl als Task ausführt (oder in Jenkins eine passende Aufgabe anlegt). Dabei muss man das gleiche Benutzerkonto verwenden und "Mit höchsten Privilegien ausführen" auswählen.

Ich würde allerdings auch sehr zur Verwendung von UNC-Pfaden raten.

[Harry Stahl]

Es funktioniert leider auch nicht mit UNC-Pfaden.

Aber evtl. habe ich ja auch etwas falsch verstanden. Die Beispiele im Internet machen es immer so, dass Sie von einem Online-Repository das Projekt in das Jenkings Workspace Directory laden und dort kompilieren.

Das will und kann ich derzeit (noch) nicht, da ich einen Ordner bzw. meherere Ordner mit Shared-Units habe. Für die habe ich mir jeweils eigene Repositories angelegt. Die Überlegung war dann u.a. wenn ich eine Änderung in einer der Shared-Units mache, mal kurz alle Projekte testen lasse, ob die nach der Änderung noch gehen, dazu wollte ich halt Jenkins (u.a.) verwenden.

Hier mal, was in meiner build.bat steht, die im Ornder "Jobs" liegt:

Code:

call "C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\rsvars.bat"
cd %1
msbuild %2

Und hier das, was ich imm Jenkins-Build-Step drin stehen habe:

Code:

call "%JENKINS_HOME%\jobs\build.bat" "\\EW0\P\DEV\DX10\PDFMAN" PDFManager.dproj

Aber das kommt dabei raus:

Code:

Gestartet durch Benutzer Harry Stahl
Running as SYSTEM
Baue in Arbeitsbereich C:\Users\Harry-Dev\AppData\Local\Jenkins\.jenkins\workspace\CompilePDFManagerRelease
[CompilePDFManagerRelease] $ cmd /c call C:\Users\HARRY-~2\AppData\Local\Temp\jenkins5243078457989210909.bat

C:\Users\Harry-Dev\AppData\Local\Jenkins\.jenkins\workspace\CompilePDFManagerRelease>call "C:\Users\Harry-Dev\AppData\Local\Jenkins\.jenkins\jobs\build.bat" "\\EW0\P\DEV\DX10\PDFMAN" PDFManager.dproj 

C:\Users\Harry-Dev\AppData\Local\Jenkins\.jenkins\workspace\CompilePDFManagerRelease>call "C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\rsvars.bat" 

C:\Users\Harry-Dev\AppData\Local\Jenkins\.jenkins\workspace\CompilePDFManagerRelease>cd "\\EW0\P\DEV\DX10\PDFMAN" 
"\\EW0\P\DEV\DX10\PDFMAN" 
CMD unterstützt keine UNC-Pfade als aktuelles Verzeichnis.

C:\Users\Harry-Dev\AppData\Local\Jenkins\.jenkins\workspace\CompilePDFManagerRelease>msbuild PDFManager.dproj 
Microsoft (R)-Buildmodul, Version 4.8.9037.0
[Microsoft .NET Framework, Version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

MSBUILD : error MSB1009: Die Projektdatei ist nicht vorhanden.
Schalter: PDFManager.dproj

C:\Users\Harry-Dev\AppData\Local\Jenkins\.jenkins\workspace\CompilePDFManagerRelease>exit 1 
Build step 'Windows Batch-Datei ausführen' marked build as failure
Finished: FAILURE

[jaenicke]

Bei UNC-Pfaden kann dann, da es ja der gleiche Benutzer ist, fast nur noch sein, dass die Policies es Diensten verbieten auf Netzwerkressourcen zuzugreifen. Das ist nicht unüblich. Ich weiß aber nur, dass das geht, nicht wie die Policy konkret heißt. Da müsstest du mal schauen.

Bezüglich deiner Shared Units:
Das ist doch gar kein Problem. Ich habe auch aus einem Repository die gemeinsamen Units ausgecheckt und aus einem weiteren die konkreten Projekte. Dafür ist Jenkins doch gut geeignet.

[Delphi.Narium]

Diese Meldung ist aufgefallen?

Code:

CMD unterstützt keine UNC-Pfade als aktuelles Verzeichnis.

cd \\unc\wasauchimmer geht mit der Kommandozeile nicht.

Damit startet msbuild dann in C:\Users\Harry-Dev\AppData\Local\Jenkins\.jenkins\workspace\Compi lePDFManagerRelease

und dort ist die PDFManager.dproj nicht zu finden.

Vielleicht geht ja sowas in der Art:

Code:

:rem build.bat
call "C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\rsvars.bat"
msbuild %1

:rem Aufruf
call "%JENKINS_HOME%\jobs\build.bat" "\\EW0\P\DEV\DX10\PDFMAN\PDFManager.dproj"

[Harry Stahl]

Zitat von jaenicke:

Bei UNC-Pfaden kann dann, da es ja der gleiche Benutzer ist, fast nur noch sein, dass die Policies es Diensten verbieten auf Netzwerkressourcen zuzugreifen. Das ist nicht unüblich. Ich weiß aber nur, dass das geht, nicht wie die Policy konkret heißt. Da müsstest du mal schauen.

Ja, bei einem lokalen Systemkonto gibt es immer dieser Beschränkung (aus Sicherheitsgründen), wüsste auch nicht das man das ändern könnte.

Der Dienst läuft aber schon unter meinem Benutzernamen (also im Eigenschaften-Dialog des Dienstes "Dieses Konto" und nicht "Lokales Systemkonto").

[Harry Stahl]

Zitat von jaenicke:

Bezüglich deiner Shared Units:
Das ist doch gar kein Problem. Ich habe auch aus einem Repository die gemeinsamen Units ausgecheckt und aus einem weiteren die konkreten Projekte. Dafür ist Jenkins doch gut geeignet.

Noch mal hier eine Nachfrage: Ich bin ja nun mal als Einzelentwickler unterwegs und da sehe ich für mich keinen Sinn darin, erst mal die Dateien aus dem (Online) Repository in ein lokales Workspace von jenkins zu laden und da zu kompilieren (zumal bei den meisten meiner Programme irgendwelche DLL's, Datenbanken, Bilder, Vorlagen, etc. im Programmverzeichnis liegen müssen).

Insofern erstelle ich den Build daher da, wo ich auch entwickle.

Wie gesagt, meine Überlegung ist, nach Änderung in den shared units alle projekte, welche diese verwenden, einmal durchlaufen zu lassen, incl. Unittests. In der Vergangenheit wurde ich nämlich hin und wieder bei solchen Änderungen davon überrascht, dass danach ein anderes Projekt sich nicht mehr kompilieren ließ, das will ich hiermit sofort mitbekommen und entsprechend gegensteuern.

Deine Lösung sieht dann aber schon so aus, dass Du die shared units in separaten Ordnern hältst und sie aus separaten Repositories lädst?