Apps: "GitLab Runner v10.1+ (до v10.5 точно)".
Задача: решить проблему с невозможностью повторного, в рамках сеанса, подключения "runner"-а к серверу "GitLab".
Начиная с "v10.1" (и до "v10.5" включительно, а может и далее) CI/CD-агент "GitLab Runner" стал сбоить при повторном подключении к серверу "GitLab" - на этапе актуализации уже полученного репозитория запросом "git fetch". Сбой прерывал последовательную отработку "pipelines" и сопровождался сообщениями об ошибке доступа к SSL-сертификату, подписывающему сеанс связи с сервером хранения репозитория:
Running with gitlab-runner 10.5.0
....
fatal: unable to access 'https://gitlab-ci-token:xx...xx@gitlab.example.net/group/repo.git/': Problem with the SSL CA cert (path? access rights?)
ERROR: Job failed: exit status 1
....
fatal: unable to access 'https://gitlab-ci-token:xx...xx@gitlab.example.net/group/repo.git/': Problem with the SSL CA cert (path? access rights?)
ERROR: Job failed: exit status 1
Недолгое расследование выявило, что проблема заключается в дублировании части пути в файловой системе к SSL-сертификату, зафиксированном в динамически формируемом конфигурационном файле загруженного "runner"-ом Git-репозитория, объединяющем в себе настройки как самого репозитория, так и агента:
# cat /var/tmp/build/.builds/1234567/0/group/repo/.git/config
....
[http "https://gitlab.example.net"]
sslCAInfo = /var/tmp/build/.builds/1234567/0/group/repo/.builds/1234567/0/group/repo.tmp/CI_SERVER_TLS_CA_FILE
....
[http "https://gitlab.example.net"]
sslCAInfo = /var/tmp/build/.builds/1234567/0/group/repo/.builds/1234567/0/group/repo.tmp/CI_SERVER_TLS_CA_FILE
....
Можно заметить, что указанный в конфигурационном файле путь к сертификату отличается от реального лишними строчными данными "/.builds/1234567/0/group/repo".
Сразу приходит в голову попробовать вырезать из строки лишнее на каком-то этапе отработки "pipelines" - но это грубое вмешательство в работу приложения, о котором нужно будет помнить при каждом обновлении конфигурации, и оно будет незаметно непосвящённым.
Поиски более практичного решения показали, что аутентификация посредством SSL-сертификата используется только для уточняющих (повторных) запросов "git fetch" - то есть она не является обязательной, после уже проведённой проверки регистрации "runner"-а по выделенному ему "токену". Если схема локальна, доступ к серверам ограничен и осуществляется по HTTPS/SSH, то можно просто отказаться от дополнительной проверки подлинности при повторных обращениях к центральному репозиторию, взведя в YAML-файле автоматизации соответствующий флаг:
$ vi .gitlab-ci.yml
variables:
# (bypass bug "git fetch": "problem with the SSL CA cert path")
GIT_SSL_NO_VERIFY: true
....
# (bypass bug "git fetch": "problem with the SSL CA cert path")
GIT_SSL_NO_VERIFY: true
....
Как я упомянул выше, дополнительная аутентификация SSL-сертификатом запрашивается только при актуализации загруженного уже репозитория посредством "git fetch". Отсюда для репозиториев небольших объёмов напрашивается второй вариант обхода проблемы - самым топорным образом принудительно перевести "runner" в режим загрузки полной копии данных посредством "git clone" на каждом этапе автоматизации, без использования "git fetch":
$ vi .gitlab-ci.yml
variables:
# (bypass bug "git fetch": "problem with the SSL CA cert path")
GIT_STRATEGY: clone
....
# (bypass bug "git fetch": "problem with the SSL CA cert path")
GIT_STRATEGY: clone
....
Оба приведённых варианта работают, и до поры можно ими пользоваться. Насколько я уловил, в "GitLab Runner v11+" ошибку сохранения некорректного пути к SSL-сертификату исправили, но на стабильных системах до сих пор эксплуатируется "v10.x".