应用错误收集

编辑：正如Rekovni指出的那样，在Windows计算机上将GitLab运行程序与Docker一起使用是一个问题。 在基于Linux的虚拟机中安装运行程序即可解决此问题。

我正在使用conda环境开发Python程序。它托管在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.com随附的共享GitLab运行程序运行此脚本，并生成文档并将其放置在公用文件夹中。

对于以后的单元测试（需要更长的时间），我想在网络中的Win 10机器上提供本地运行程序。为此，我安装了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]

现在的问题是，本地运行程序在执行上述脚本期间冻结，而没有产生任何错误消息，我不知道如何调试它。我拥有的是

在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行。

关于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循环中。

有人知道吗？

本地运行程序失败的原因可能是什么（当同一脚本与共享运行程序一起工作时）？
该如何调试该问题？

非常感谢，托马斯

GitLab CI目前尚不提供在Windows环境中将其运行器与Docker结合使用的解决方案，但是目前有一个epic正在跟踪其进展。

在史诗的issues之一中，贡献者设法获得了一个gitlab-runner的工作版本，该版本使用Docker for Windows，有关更多详细信息，请参见here。 / p>

在Windows环境中使用Docker的一种更常见（且可能更容易）的方法是将gitlab-runner安装为Shell运行器，并手动调用Docker命令以运行测试。

相反，如果您只想继续使用相同的CI脚本，则可以在Windows 10计算机上安装Linux VM，并托管Docker运行程序！

本地GitLab运行程序冻结，而共享GitLab.com运行程序成功

1 个答案: