GitLab Runner: знайдіть налаштування проксі для невдалого етапу завдання
Керування Runner, отримання образу, отримання репозиторію та завантаження всередині завдання можуть походити з різних процесів.
| Перша помилка | Вхідні дані для перевірки |
|---|---|
| Runner звертається до GitLab | Середовище служби Runner |
| Завантаження образу завдання | Служба демона/завантаження Docker |
| Отримання репозиторію | Фактичне середовище клієнта/помічника Git |
| Завантаження команди завдання | Контейнер і власні клієнтські налаштування цього інструмента |
Змінна завдання надходить запізно для завантаження образу, яке вже потрібне для створення контейнера. Успішне керівне з'єднання Runner також не може забезпечити доступність ізольованого завдання.
Для 127.0.0.1:3128 знайдіть слухача: loopback контейнера завдання — не хост Runner. Надавайте доступ до помічника на хості лише потрібним мережам завдань і свідомо керуйте його висхідним обліковим записом.
Застосуйте підтримуваний інтерфейс розгорнутого Runner/виконавця, потім залежні від версії параметри фактичного завантажувача. Зберігайте етап, процес-запитувач і випробувану кінцеву точку у відредагованій діагностиці, а не вносьте припущення, специфічні для облікового запису, у спільні обгортки.