Fehler bei Pipeline läufen

Heute früh liefen 12 der 48 konfigurierten Automatisierungen gestaffelt ab 0Uhr los. Von den 12 sind 3 leider auf Fehler gelaufen, nutzten aber die selbe Pipeline wie die anderen 9 Automatisierungen. Alle 3 habe ich heute morgen erneut gestartet und sie liefen ohne Fehler durch. Zwei der Fehler betrafen die Skriptsignierung und ein Fehler betraf die Paketverfügbarkeit im neo42 APD.

Gibt es da eine Möglichkeit einzubauen, dass bei einem Fehler der selbe Vorgang nach einer Zeitspanne (eine Stunde oder so) erneut läuft? Oder eine andere Möglichkeit die Pipeline weniger anfällig für Fehler zu machen?

Anbei die 3 Logs der fehlerhaften Pipeline Ausführungen (leider sind keine TXT oder LOG Formate erlaubt als Dateianhang).

Fehler 1:
09.09.2024 00:04:18

Beim signieren der Datei „D:\neo42\APC\PipelineAgent\Work\1c4ef43f-bd03-4036-bdca-fea6e1359fb1\Empirum*.ps1“ ist ein Fehler ‚Failed to sign script ‚D:\neo42\APC\PipelineAgent\Work\1c4ef43f-bd03-4036-bdca-fea6e1359fb1\Empirum\24193.1805.3040.8975\PSADT\AppDeployToolkit\AppDeployToolkitMain.ps1‘. Abort!‘ aufgetreten.

Fehler 2:
09.09.2024 00:04:18

Beim signieren der Datei „D:\neo42\APC\PipelineAgent\Work\75c269d8-aecc-41d5-b721-7784b566b5f8\Empirum*.ps1“ ist ein Fehler ‚Failed to sign script ‚D:\neo42\APC\PipelineAgent\Work\75c269d8-aecc-41d5-b721-7784b566b5f8\Empirum\128.0.2739.67\PSADT\ApplyEmpirumVars.ps1‘. Abort!‘ aufgetreten.

Fehler 3:
09.09.2024 00:06:07

Paket mit der ID ‚66cf61296f4a3ca35f10cade‘ wurde nicht im Service Portal gefunden. Bitte versuchen Sie es nach einer forcierten Synchronisation der Paketliste erneut.

Interessanterweise traten Fehler 1 und 2 zur selben Uhrzeit auf, obwohl die jeweilige Automatisierung nicht zur selben Zeit gestartet wurde ( 0:03Uhr und 0:04Uhr). Würde es hier helfen den Zeitabstand der Automatisierungen zu vergrößern? Momentan starte ich um 0:00Uhr im Minutenabstand bis 0:47Uhr.

Hallo @LRARMK

Erstmal finde ich es klasse zu lesen, dass ihr bereits 48 Automatisierungen im APC angelegt habt! Zeigt mir, dass das APC einen vorhanden Bedarf komfortabel über die UI löst.

Alle 3 Fehler könnten als Ursache haben, dass die Internetverbindung gestört ist. Für die Signatur wird wegen dem Zeitserver eine Verbindung benötigt und für das Abrufen der Paketinformationen natürlich auch. Vielleicht ist die Leitung durch die vielen zusammenliegenden Automatisierungen zu stark belastet? Wenn sich das als Möglicher Flaschenhals herausstellt, dann würde ich auf jeden Fall empfehlen die Zeiträume zwischen den einzelnen Läufen zu verlängern.

Bitte sende uns die aktuellen Logdateien des Servers (%ProgramData%\neo42\Management Service\log) an neosupport@neo42.de - dann lassen sich vllt noch andere Ursachen und mögliche Verbesserungen im Code ermitteln.

Gruß
Marco

Logs zugeschickt. Habe auch kurz reingeschaut, sieht wirklich so aus als wäre da entweder generell das Internet, bzw. der Proxyserver nicht verfügbar gewesen. Da dieser bei unserem Rechenzentrum läuft habe ich dort keinerlei Einsicht ob dieser evtl. kurz gestört war (sind eigentlich geclustert).

Eine Funktion solche abgebrochenen Läufe automatisch zu wiederholen wäre wirklich praktisch.

Über das Thema „Pipeline Retry“ haben wir intern auch schon viel diskutiert.
Was sich im ersten Moment so einfach anhört ist am Ende unheimlich komplex und kann zu noch größeren Problemen führen als ein einfacher Abbruch.

Das einfachste Beispiel ist hier die Pipeline die nach dem Import in das Zielsystem noch eine Zuweisung durchführt. Angenommen der Fehler tritt bei der Zuweisung der Software auf, weil das Zielsystem kurz nicht erreichbar. Was würde bei einem Retry passieren? Die Software würde erneut heruntergeladen und entpackt werden. Danach würde dann der Import scheitern, weil es diese Software schon gibt. Weitere Retries würde dann an der selben Stelle scheitern. Man müsste also pro Schritt in der Pipeline vorher entscheiden, ob es einen Retry geben darf oder nicht, was die Komplexität sowohl in der Bedienung als auch im Backend wieder erhöhen würde.

Aus diesem Grund verfolgen wir eher das Ziel die einzelnen Tasks nach Bedarf zu verbessern und dort erweiterte Fehlerbehandlungen einzubauen. Für den Signatur Task werden wir bei nächster Gelegenheit sicherlich einen automatisch retry einbauen, wenn mal kein Internet zur Verfügung steht.