Jenkins und Netzlaufwerke

[Olli73]

Zitat von Harry Stahl:

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 von Olli73:

Zitat von Harry Stahl:

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 von himitsu:

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 von 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/

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 von 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.

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!

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

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