为什么自托管的 gitlab runner 在克隆 repo 和在自托管的 runner 上执行作业时遇到问题
Why is self-hosted gitlab runner having trouble cloning repo and executing the job on self-hosted runner
我目前正在研究 GitLab 运行器,以更好地了解它们在 CI/CD 管道环境中的工作方式。我按照 GitLab 文档中的说明创建了一个自我管理的跑步者(即我个人的 Windows 笔记本电脑):
- 安装了 GitLab Runner 可执行文件
- 在 GitLab 注册了我的跑步者
- 为我的玩具项目禁用共享跑步者
- 修改了
toml
文件以使用 powershell
作为 shell 执行程序而不是 pwsh
完成这些步骤后,我使用 GitLab web UI 创建了一个 CI/CD 管道。生成的默认 .gitlab-ci.yml
文件如下所示:
stages: # List of stages for jobs, and their order of execution
- build
- test
- deploy
build-job: # This job runs in the build stage, which runs first.
stage: build
script:
- echo "Compiling the code..."
- echo "Compile complete."
unit-test-job: # This job runs in the test stage.
stage: test # It only starts when the job in the build stage completes successfully.
script:
- echo "Running unit tests... This will take about 60 seconds."
- sleep 60
- echo "Code coverage is 90%"
lint-test-job: # This job also runs in the test stage.
stage: test # It can run at the same time as unit-test-job (in parallel).
script:
- echo "Linting code... This will take about 10 seconds."
- sleep 10
- echo "No lint issues found."
deploy-job: # This job runs in the deploy stage.
stage: deploy # It only runs when *both* jobs in the test stage complete successfully.
script:
- echo "Deploying application..."
- echo "Application successfully deployed."
基本上只有 echo
和 sleep
语句。没有力量shell无法处理。
然而,当我使用 GitLab 的网络 UI 手动触发管道时,它滞后于 build-job
如下:
最后超时如下图:
我的 .gitlab-ci.yml
文件中没有任何内容要求 Runner 从存储库中克隆任何内容。为什么它仍然试图克隆回购协议?为什么卡在这一步了?
编辑
使用 get-winevent
按照 docs 指示提取运行程序日志表明存在以下问题:
WARNING: Checking for jobs... failed
runner=WazTRLts status=couldn't execute POST against https://gitlab.com/api/v4/jobs/request: Post https://gitlab.com/api/v4/jobs/request: x509: certificate signed by unknown authority
也许这有助于理解超时发生的原因?我该如何解决这个问题?
这是任何 runner (self-managed or not) workflow
的一部分
这个想法是让您的命令(任何命令)在您的代码库上运行,该代码库首先被克隆。
关于超时和错误,参见“Self-signed certificates or custom Certification Authorities all tiers”
For connections to the GitLab server: the certificate file can be specified as detailed in the Supported options for self-signed certificates targeting the GitLab server section.
This solves the x509: certificate signed by unknown authority
problem when registering a runner.
我目前正在研究 GitLab 运行器,以更好地了解它们在 CI/CD 管道环境中的工作方式。我按照 GitLab 文档中的说明创建了一个自我管理的跑步者(即我个人的 Windows 笔记本电脑):
- 安装了 GitLab Runner 可执行文件
- 在 GitLab 注册了我的跑步者
- 为我的玩具项目禁用共享跑步者
- 修改了
toml
文件以使用powershell
作为 shell 执行程序而不是pwsh
完成这些步骤后,我使用 GitLab web UI 创建了一个 CI/CD 管道。生成的默认 .gitlab-ci.yml
文件如下所示:
stages: # List of stages for jobs, and their order of execution
- build
- test
- deploy
build-job: # This job runs in the build stage, which runs first.
stage: build
script:
- echo "Compiling the code..."
- echo "Compile complete."
unit-test-job: # This job runs in the test stage.
stage: test # It only starts when the job in the build stage completes successfully.
script:
- echo "Running unit tests... This will take about 60 seconds."
- sleep 60
- echo "Code coverage is 90%"
lint-test-job: # This job also runs in the test stage.
stage: test # It can run at the same time as unit-test-job (in parallel).
script:
- echo "Linting code... This will take about 10 seconds."
- sleep 10
- echo "No lint issues found."
deploy-job: # This job runs in the deploy stage.
stage: deploy # It only runs when *both* jobs in the test stage complete successfully.
script:
- echo "Deploying application..."
- echo "Application successfully deployed."
基本上只有 echo
和 sleep
语句。没有力量shell无法处理。
然而,当我使用 GitLab 的网络 UI 手动触发管道时,它滞后于 build-job
如下:
最后超时如下图:
我的 .gitlab-ci.yml
文件中没有任何内容要求 Runner 从存储库中克隆任何内容。为什么它仍然试图克隆回购协议?为什么卡在这一步了?
编辑
使用 get-winevent
按照 docs 指示提取运行程序日志表明存在以下问题:
WARNING: Checking for jobs... failed
runner=WazTRLts status=couldn't execute POST against https://gitlab.com/api/v4/jobs/request: Post https://gitlab.com/api/v4/jobs/request: x509: certificate signed by unknown authority
也许这有助于理解超时发生的原因?我该如何解决这个问题?
这是任何 runner (self-managed or not) workflow
的一部分这个想法是让您的命令(任何命令)在您的代码库上运行,该代码库首先被克隆。
关于超时和错误,参见“Self-signed certificates or custom Certification Authorities all tiers”
For connections to the GitLab server: the certificate file can be specified as detailed in the Supported options for self-signed certificates targeting the GitLab server section.
This solves the
x509: certificate signed by unknown authority
problem when registering a runner.