GitLab Runner 无法上传工件并出现“无效参数”错误

Phi*_*ord 7 gitlab-ci gitlab-ci-runner

我对尝试实现 GitLab 的 CI/CD 管道完全陌生,但进展顺利。事实上,对于我的 ASP.NET 项目,如果我在msbuild使用 Web Deploy 的命令中指定发布配置文件,它实际上会将代码成功部署到 Web 服务器。

但是,我现在想让“构建”作业创建工件,将其上传到 GitLab,然后我可以随后进行部署。我们正在使用 GitLab 的自托管实例,我不是该实例的管理员,但如果我知道我要什么,我可以与管理员交谈!

所以我gitlab-ci.yml像这样配置了我的文件:

variables:
  NUGET_PATH: 'C:\Program Files\Nuget\Nuget.exe'
  NUGET_SOURCES: 'https://api.nuget.org/v3/index.json'
  MSBUILD_PATH: 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin\msbuild.exe'

stages:
- build

build-job:
  variables:
    CI_DEBUG_TRACE: "true"
  stage: build
  script:
    - '& "$env:NUGET_PATH" restore ApplicationTemplate.sln  -Source "$env:NUGET_SOURCES"'
    - '& "$env:MSBUILD_PATH" ApplicationTemplate\ApplicationTemplate.csproj /p:DeployOnBuild=true /p:Configuration=Release /p:PublishProfile=FolderPublish.pubxml'
  artifacts:
    paths: 
      - '.\ApplicationTemplate\bin\Release\Publish\'
Run Code Online (Sandbox Code Playgroud)

输出显示这可以很好地构建代码,并且似乎也成功找到了要上传的工件。但是,当它上传工件时,即使请求得到响应200 OK,该过程也会失败。这是日志输出:

调试模式下 GitLab Runner 的输出屏幕截图

因此,它找到工件,尝试上传它们,甚至获得响应200 OK(与我在网上找到的有关此错误的少数类似报告相反),但由于参数无效,它仍然失败。

我已经启用了详细调试,正如您从输出中看到的那样,但我一无所知。查看托管运行程序的盒子上的 Windows 事件日志中的 GitLab 运行程序条目也无法提供任何信息。工件的总大小为 61.1MB,所以我认为我的问题与此无关。

谁能从这个输出中看出什么是无效的?我可以确定哪个参数无效和/或为什么无效?

编辑:我尝试过的事情

  • 指定 的值artifacts:expire_in
  • 设置artifacts:public为 FALSE,因为我使用的是自托管 GitLab 环境,并且此设置的默认值 (TRUE) 在此类环境中无效
  • 尝试我能想到的每种格式来获取设置的值artifacts:paths(这似乎非常强大 - 无论我使用哪种格式,运行器在解析它并找到要上传的文件时似乎都没有问题)。
  • 从这个问题中得到启发,我创建了一个新项目,其中包含一个非常简单的构建作业来上传单个文件:
stages:
  - build

build-job:
  variables:
    CI_DEBUG_TRACE: "true"
  stage: build
  script:
    - echo "Test" > test.txt
  artifacts:
    paths:
      - test.txt
Run Code Online (Sandbox Code Playgroud)

大约 50% 的时间,这项工作会因工件上传而挂起,我必须取消它。另一半时间它会以与我之前的项目完全相同的方式失败:

来自 GitLab 的日志信息的屏幕截图

Phi*_*ord 6

经过无数个小时的研究,似乎最终的问题是我们的内部 Web 应用程序防火墙阻止了将工件传输到服务器的某些部分,或者阻止了从服务器返回的响应。将 WAF 重新配置为不阻止来自运行 GitLab Runner 的计算机的流量后,工件将成功上传,作业也会成功。

如果 GitLab 的日志记录更好的话,诊断起来会容易得多。根据我对此问题的评论,上传工件后应该可以看到来自 GitLab 服务器的响应内容,即使响应代码是200.

奇怪的是,当我与 GitLab 实例的管理员一起解决问题、挖掘日志并在调试模式下运行它时,工件上传过程正在成功上传某些内容,这使得诊断问题变得更加困难。例如,我们可以看到 GitLab Runner 的日志已上传到服务器。显然,WAF 的阻止是有选择性的,并没有阻止两个方向上的所有内容。