GitLab Runner: Die Proxy-Einstellungen für die fehlgeschlagene Job-Phase finden
Runner-Steuerung, Image-Abruf, Repository-Abruf und Downloads innerhalb des Jobs können von unterschiedlichen Prozessen ausgehen.
| Erster Fehler | Zu prüfende Eingabe |
|---|---|
| Runner kontaktiert GitLab | Umgebung des Runner-Dienstes |
| Job-Image ziehen | Docker-Daemon/Pull-Dienst |
| Repository abrufen | Tatsächliche Git-Client-/Helper-Umgebung |
| Download des Job-Befehls | Der Container und die eigenen Client-Einstellungen dieses Werkzeugs |
Eine Job-Variable kommt zu spät für einen Image-Pull, der bereits zum Erstellen des Containers nötig ist. Eine erfolgreiche Runner-Steuerverbindung kann ebenso wenig die Erreichbarkeit eines isolierten Jobs herstellen.
Suchen Sie für 127.0.0.1:3128 den Listener: Das Loopback des Job-Containers ist nicht der Runner-Host. Geben Sie nur den vorgesehenen Job-Netzwerken Zugriff auf einen Host-Helper und verwalten Sie dessen Upstream-Konto bewusst.
Wenden Sie die unterstützte Schnittstelle des eingesetzten Runners/Executors an und dann die versionsgebundenen Optionen des tatsächlichen Downloaders. Halten Sie Phase, anfragenden Prozess und versuchten Endpunkt in redigierten Diagnosen fest, statt kontospezifische Vermutungen in gemeinsame Wrapper zu schreiben.