Jenkins und Netzlaufwerke

[Harry Stahl]

Ich habe Jenkins in meiner virtuellen Maschine auf dem C:\ Laufwerk installiert.

Alle unter "Freestyle" angelegte Projekte, die einen Aufruf auf ein Netzwerklaufwerk beinhalten (hier eingebunden als "D:\"), funktionieren nicht (Laufwerk bzw. oder Pfad nicht gefunden)". Alle CD Laufwerk-Befehle oder auch PushD-Befehle gehen nicht (also nicht "cd C:\DEV\DX10\PFDMain" ).

Die gleichen Befehle in einer Batch-Datei unter einem DOS-Prompt aufgerufen funktionieren.

Ist das irgendeine Einschränkung oder eine bekannte Problematik von Jenkins?

[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:

Zitat von jaenicke (Beitrag 1529951)

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:

Zitat von Delphi.Narium (Beitrag 1529952)

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"

Ja, danke, hatte ich natürlich auch schon versucht hier die vollständige Pfadangabe zu verwenden.

Aber dann kommt diese Fehlermeldung:

Code:

Der Buildvorgang wurde am 22.11.2023 19:29:46 gestartet.
Projekt "\\EW0\P\DEV\DX10\PDFMAN\PDFManager.dproj" auf Knoten "1" (Standardziele).
CreateProjectDirectories:
  Das Verzeichnis D:\DEV\DX10\PDFMAN\ wird erstellt.
  md "D:\DEV\DX10\PDFMAN\"
C:\Program Files (x86)\Embarcadero\Studio\22.0\Bin\CodeGear.Delphi.Targets(784,5): error MSB3191: Das Verzeichnis D:\DEV\DX10\PDFMAN\ kann nicht erstellt werden. Ein Teil des Pfades "D:\DEV\DX10\PDFMAN\" konnte nicht gefunden werden. [\\EW0\P\DEV\DX10\PDFMAN\PDFManager.dproj]
Die Erstellung des Projekts "\\EW0\P\DEV\DX10\PDFMAN\PDFManager.dproj" ist abgeschlossen (Standardziele) -- FEHLER.

Wobei mir unverständlich ist, dass da versucht wird, das Verzeichnis (das schon besteht), zu erzeugen....

[Olli73]

Zitat:

Zitat von Harry Stahl (Beitrag 1529957)

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

Und was hat das

Zitat:

Running as SYSTEM

zu bedeuten?

[Harry Stahl]

Zitat:

Zitat von Olli73 (Beitrag 1529960)

Zitat:

Zitat von Harry Stahl (Beitrag 1529957)

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

Und was hat das

Zitat:

Running as SYSTEM

zu bedeuten?

Das hat mich auch etwas irritiert. Hätte da eigentlich meinen Benutzernamen erwartet.
Aber wie gesagt, den laufenden Dienst aus dem Dienstemanager rausgepickt, Eigenschaft, Register Anmelden und dort ist ganz klar mein Benutzer-Konto ausgewählt.

[himitsu]

fehlende LoginDaten für das UNC-Laufwerk?

[Harry Stahl]

Zitat:

Zitat von himitsu (Beitrag 1529962)

fehlende LoginDaten für das UNC-Laufwerk?

Wo sollen die fehlen?

[Olli73]

Ich glaube du brauchst das "Authorize Project Plugin", um den Build als "user who triggered the build" laufen zu lassen:

https://www.jenkins.io/doc/book/secu...authorization/

[Harry Stahl]

Zitat:

Zitat von Olli73 (Beitrag 1529967)

Ich glaube du brauchst das "Authorize Project Plugin", um den Build als "user who triggered the build" laufen zu lassen:

https://www.jenkins.io/doc/book/secu...authorization/

Gute Idee, habe ich installiert und auf Ausführen unter Benutzer umgestellt. Das funktioniert auch, trotzdem findet er den Pfad nicht, bzw. macht so seltsame Dinge wie das Verzeichnis neu erstellen zu wollen.

Vielleicht ist die Kombi Linux Host, Windows in der Virtual-BOX VM und Netzlaufwerk des Linux-Hosts irgendwie zu speziell?

Code:

Gestartet durch Benutzer Harry Stahl
Build wird als „Harry Stahl“ ausgeführt
Baue in Arbeitsbereich C:\Users\Harry-Dev\AppData\Local\Jenkins\.jenkins\workspace\CompilePDFManagerRelease
[CompilePDFManagerRelease] $ cmd /c call C:\Users\HARRY-~2\AppData\Local\Temp\jenkins3426869873806309641.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" "\\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 "\\EW0\P\DEV\DX10\PDFMAN\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.

Der Buildvorgang wurde am 22.11.2023 20:24:42 gestartet.
Projekt "\\EW0\P\DEV\DX10\PDFMAN\PDFManager.dproj" auf Knoten "1" (Standardziele).
CreateProjectDirectories:
  Das Verzeichnis D:\DEV\DX10\PDFMAN\ wird erstellt.
  md "D:\DEV\DX10\PDFMAN\"
C:\Program Files (x86)\Embarcadero\Studio\22.0\Bin\CodeGear.Delphi.Targets(784,5): error MSB3191: Das Verzeichnis D:\DEV\DX10\PDFMAN\ kann nicht erstellt werden. Ein Teil des Pfades "D:\DEV\DX10\PDFMAN\" konnte nicht gefunden werden. [\\EW0\P\DEV\DX10\PDFMAN\PDFManager.dproj]
Die Erstellung des Projekts "\\EW0\P\DEV\DX10\PDFMAN\PDFManager.dproj" ist abgeschlossen (Standardziele) -- FEHLER.

Fehler beim Buildvorgang.

"\\EW0\P\DEV\DX10\PDFMAN\PDFManager.dproj" (Standardziel) (1) ->
(CreateProjectDirectories Ziel) -> 
  C:\Program Files (x86)\Embarcadero\Studio\22.0\Bin\CodeGear.Delphi.Targets(784,5): error MSB3191: Das Verzeichnis D:\DEV\DX10\PDFMAN\ kann nicht erstellt werden. Ein Teil des Pfades "D:\DEV\DX10\PDFMAN\" konnte nicht gefunden werden. [\\EW0\P\DEV\DX10\PDFMAN\PDFManager.dproj]

    0 Warnung(en)
    1 Fehler

Verstrichene Zeit 00:00:00.68

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

[Olli73]

UNC-Pfade würde ich nicht nutzen, wegen Problemen mit Batch-Dateien (siehe Meldung). Des weiteren probiere mal in deiner Batch-Datei anstatt

Code:

cd %1

ein

Code:

cd /D %1

; das stellt auch das Laufwerk mit um.

Wenn das nicht hilft würde ich in der Batch-Datei Mal zuerst ein

Code:

net use ...

ausprobieren.

[himitsu]

Statt CD (ChangeDir) auch mal ein PUSHD (PushDir) probieren.
Es erstellt dort, bei Netzlaufwerken, einen Laufwerksbuchstaben.
Aber nicht das POPD vergessen (entfernt wieder das Laufwerk, aus der aktuellen WindowsSession)

CMD kann nicht mit Netzlaufwerken als Arbeitsverzeichnis umgehen.

https://ss64.com/nt/pushd.html
https://ss64.com/nt/popd.html
https://learn.microsoft.com/de-de/wi...commands/pushd

[Harry Stahl]

Zitat:

Zitat von Olli73 (Beitrag 1529974)

UNC-Pfade würde ich nicht nutzen, wegen Problemen mit Batch-Dateien (siehe Meldung). Des weiteren probiere mal in deiner Batch-Datei anstatt

Code:

cd %1

ein

Code:

cd /D %1

; das stellt auch das Laufwerk mit um.

Wenn das nicht hilft würde ich in der Batch-Datei Mal zuerst ein

Code:

net use ...

ausprobieren.

Der veränderte "cd" Aufruf hat nichts gebracht, aber die Verwendung von net use.

Meine build.bat Batch-Datei hatte ich wie folgt angepasst:

Code:

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

Dann hat es es funktioniert!:thumb:

Danke für die Unterstützung. Jetzt kann ich mich so richtig mit Automatisationsvorhaben austoben...:-D

[Harry Stahl]

Zitat:

Zitat von jaenicke (Beitrag 1529951)

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?

[TiGü]

Zitat:

Zitat von Harry Stahl (Beitrag 1529980)

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?

Also bei uns ist es üblich für ein Release, dass aus drei einzelnen SVN-Repositories die jeweiligen Quelltextstände in den Workspace geladen werden und dann werden die durch eine gemeinsame Batch-Datei gebaut.
Erst unsere eigenen visuellen Komponenten, dann das Delphi-Gruppenprojekt, welches die Haupt-EXE (Repo 1) und dazugehörigen DLLs (Repo 2) in ein gemeinsames Verzeichnis baut.
Anschließend laufen als nächste Build-Steps per Batch-Datei noch die Übersetzung und das Erstellen des Setups.

[jaenicke]

Zitat:

Zitat von Harry Stahl (Beitrag 1529980)

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

Sonst kannst du doch gar nicht richtig testen. Wichtig ist dabei genau, dass die Daten aus dem Repository ausgecheckt werden, damit man genau den eingecheckten Versionsstand prüft und nicht den, der irgendwo als Datei liegt.

Ob man Einzelentwickler ist oder nicht, spielt dabei keine Rolle. Ich mache das für meine Hobbyprojekte, für die ich nur wenig Zeit habe, ganz genauso, ganz einfach weil das am Ende sehr viel Zeit und Mühe spart.