РЕДАКТИРОВАТЬ: Как отметил Rekovni, использование GitLab Runner с Docker на компьютере с Windows является проблемой. Установка бегуна в виртуальной машине на основе Linux решила проблему.
Я занимаюсь разработкой программы на Python с использованием среды conda.Он размещен на GitLab.com, и я использую GitLab-CI для создания документации.
Я настроил для него следующий файл .gitlab-ci.yml:
image: continuumio/miniconda3:latest
before_script:
# Update conda and create environment, which is then activated.
- conda update -vvv -y -c conda-forge conda
- conda env create -f helpers/NAME.yml
- source activate NAME
# Correct installation.
- conda install -q -y gsl=2.2.1
pages:
script:
# Install make.
- apt-get update
- apt-get install -q -y build-essential
# Install Spinx-related packages.
- conda install -q -y sphinx sphinx_rtd_theme
# Create documentation.
- cd REPO/doc
- sphinx-apidoc -o source/ ../REPO --force --separate
- make html
# Transfer documentation to public pages folder.
- mv build/html/ ../../public/
artifacts:
paths:
- public
# only:
# - master
Запуск этого сценария собщий GitLab Runner, который поставляется с GitLab.com, работает, а документация генерируется и помещается в общую папку.
Для будущих юнит-тестов (которые занимают гораздо больше времени) я хочу предоставить локальный бегун на Win10 машин в моей сети.Для этого я установил gitlab-runner.exe и Docker Desktop.Я успешно зарегистрировал бегуна в проекте на GitLab.com.
Бегун использует следующий файл конфигурации config.toml:
concurrent = 1
check_interval = 0
log_level = "info"
[session_server]
session_timeout = 1800
[[runners]]
name = "NAME"
url = "https://gitlab.com"
token = "TOKEN"
executor = "docker"
[runners.custom_build_dir]
[runners.docker]
tls_verify = false
image = "alpine:latest"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
Проблема заключается в том, что локальный бегун зависает во времявыполнение приведенного выше сценария без каких-либо сообщений об ошибках, и я не знаю, как его отладить.У меня есть
- Журнал скрипта, который показан на странице Job на GitLab.com;и
- Консольный вывод
gitlab-runner.exe на локальной машине.
Относительно 1. Я вижу
[0KRunning with gitlab-runner 11.10.0 (3001a600)
...
[32;1mChecking out COMMIT_HASH as BRANCH_NAME...[0;m
...
[0K[32;1m$ conda update -vvv -y -c conda-forge conda[0;m
DEBUG conda.gateways.logging:set_verbosity(148): verbosity set to 3
...
...
...
TRACE conda.gateways.disk.update:rename(52): renaming /opt/conda/share/doc/openssl/html/man3/OSSL_STORE_LOADER_new.html => /opt/conda/share/doc/openssl/html/man3/OSSL_STORE_LOADER_new.html.c~
TRACE conda.core.path_actions:execute(1041): renaming share/doc/openssl/html/man3/OSSL_STORE_LOADER_set_close.html => share/doc/openssl/html/man3/OSSL_STORE_LOADER_set_close.html.c~
TRACE conda.gateways.disk.update:rename(52): renaming /opt/conda/share/doc/openssl/html/man3/OSSL_STORE_LOADER_set_close.html => /opt/conda/share/doc/openssl/html/man3/OSSL_STORE_LOADER_set_close.html.c~
TRACE conda.core.path_actions:execute(1041): renaming share/doc/openssl/html/man3/OSSL_STORE_LOADER_set_ctrl.html => share/doc/openssl/html/man3/OSSL_STORE_LOADER_set_ctrl.html.c~
, где он внезапно останавливается, не достигая- conda env create -f helpers/NAME.yml line.
Что касается 2., я вижу
C:\GitLab-Runner>gitlab-runner.exe --debug run
Runtime platform arch=amd64 os=windows pid=14116 revision=3001a600 version=11.10.0Starting multi-runner from C:\GitLab-Runner\config.toml ... builds=0
Checking runtime mode GOOS=windows uid=-1
Configuration loaded builds=0
...
Feeding runners to channel builds=0
Checking for jobs... nothing runner=TOKEN
Feeding runners to channel builds=0
Checking for jobs... received job=203033130 repo_url=REPO_URL.git runner=TOKEN
...
Attaching to container HASH ... job=203033130 project=6249897 runner=TOKEN
Starting container HASH ... job=203033130 project=6249897 runner=TOKEN
Waiting for attach to finish HASH ... job=203033130 project=6249897 runner=TOKEN
Waiting for container HASH ... job=203033130 project=6249897 runner=TOKEN
Appending trace to coordinator... ok code=202 job=203033130 job-log=0-10348 job-status=running runner=TOKEN sent-log=1801-10347 status=202 Accepted
Appending trace to coordinator... ok code=202 job=203033130 job-log=0-19445 job-status=running runner=TOKEN sent-log=10348-19444 status=202 Accepted
...
Appending trace to coordinator... ok code=202 job=203033130 job-log=0-933150 job-status=running runner=TOKEN sent-log=241860-933149 status=202 Accepted
Submitting job to coordinator... ok code=200 job=203033130 job-status= runner=TOKEN
Submitting job to coordinator... ok code=200 job=203033130 job-status= runner=TOKEN
, где кажется, что переключение с Appending trace to coordinator на Submitting job to coordinator происходит примерно в то время, когда оно застревает.После этого 1. не обновляется никакой дополнительной информацией и 2. застревает в цикле Submitting job to coordinator.
Кто-нибудь знает:
- В чем причина сбоя сможет быть местный бегун (когда тот же сценарий работает с общим бегуном)?
- Что я могу сделать для устранения этой проблемы?
Спасибо и всего наилучшего, Томас