GitLab Runner : trouver les paramètres de proxy de l'étape de job échouée
Le contrôle du Runner, la récupération de l'image, celle du dépôt et les téléchargements dans le job peuvent provenir de processus différents.
| Premier échec | Entrée à inspecter |
|---|---|
| Le Runner contacte GitLab | Environnement du service Runner |
| Tirer l'image du job | Service démon/tirage Docker |
| Récupérer le dépôt | Environnement réel du client/assistant Git |
| Téléchargement de la commande du job | Le conteneur et les propres paramètres client de cet outil |
Une variable de job arrive trop tard pour un tirage d'image déjà nécessaire à la création du conteneur. Une connexion de contrôle Runner réussie ne peut pas non plus établir l'accessibilité d'un job isolé.
Pour 127.0.0.1:3128, localisez l'écouteur : le loopback du conteneur de job n'est pas l'hôte du Runner. N'accordez l'accès à un assistant de l'hôte qu'aux réseaux de jobs prévus et gérez son compte amont de manière délibérée.
Appliquez l'interface prise en charge du Runner/executor déployé, puis les options versionnées du téléchargeur réel. Conservez l'étape, le processus demandeur et le point de terminaison essayé dans des diagnostics expurgés plutôt que de placer des suppositions propres au compte dans des enveloppes partagées.