GitLab Runner 无法上传带有 "invalid argument" 错误的工件
GitLab Runner fails to upload artifacts with "invalid argument" error
我对尝试实施 GitLab 的 CI/CD 管道完全陌生，但进展顺利。事实上，对于我的 ASP.NET 项目，如果我在使用 Web 部署的 msbuild 命令中指定发布配置文件，它实际上会将代码成功部署到 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 Studio22\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\'
输出显示这构建代码很好，而且似乎也成功找到了要上传的工件。但是，当它上传工件时，即使请求获得 200 OK 响应，该过程也会失败。这是日志输出：
所以，它找到了工件，它尝试上传它们，甚至得到 200 OK 响应（与我在网上找到的少数类似的错误报告形成对比），但是由于参数无效，它仍然失败。
我已经启用了详细调试，正如您从输出中看到的那样，但我 none 更聪明。在托管跑步者的框中查看 Windows 事件日志中的 GitLab 跑步者条目也不会阐明任何事情。工件的总大小为 61.1MB，因此我认为我的问题与此无关。
谁能从这个输出中看出什么是无效的？我可以确定哪个参数无效 and/or 为什么它无效？
编辑：我尝试过的事情
- 为
artifacts:expire_in. 指定一个值
- 将
artifacts:public 设置为 FALSE，因为我使用的是自托管 GitLab 环境和 the default value for this setting (TRUE) is not valid in such an environment。
- 尝试我能想到的每一种格式来获取
artifacts:paths 设置的值（这似乎非常可靠 - 无论我使用哪种格式，Runner 似乎都可以毫无问题地解析它并找到要上传的文件）。
- 从
中得到启发，我用一个非常简单的构建作业创建了一个新项目来上传单个文件：
stages:
- build
build-job:
variables:
CI_DEBUG_TRACE: "true"
stage: build
script:
- echo "Test" > test.txt
artifacts:
paths:
- test.txt
这项工作大约有 50% 的时间在上传工件时挂起，我不得不取消它。另一半时间它以与我之前的项目完全相同的方式失败：
经过无数小时的努力，最终问题似乎是我们的内部 Web 应用程序防火墙阻止了将工件传输到服务器或从服务器返回的响应的某些部分。将 WAF 重新配置为不阻止来自机器 运行 GitLab Runner 的流量，工件已成功上传并且作业成功。
如果来自 GitLab 的日志记录更好，这将更容易诊断。根据我对 this issue 的评论，即使响应代码为 200.
，也应该可以在上传工件后看到来自 GitLab 服务器的响应内容
奇怪的是 - 并且使问题的诊断更加困难 - 当我与我们的 GitLab 实例的管理员一起解决问题，挖掘日志并 运行 它处于调试模式时，工件上传过程是 上传内容成功。例如，我们可以看到 GitLab Runner 的日志已经上传到服务器。很明显，WAF 的阻塞是有选择性的，并没有双向阻塞。
我对尝试实施 GitLab 的 CI/CD 管道完全陌生，但进展顺利。事实上，对于我的 ASP.NET 项目，如果我在使用 Web 部署的 msbuild 命令中指定发布配置文件，它实际上会将代码成功部署到 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 Studio22\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\'
输出显示这构建代码很好，而且似乎也成功找到了要上传的工件。但是，当它上传工件时，即使请求获得 200 OK 响应，该过程也会失败。这是日志输出：
所以，它找到了工件，它尝试上传它们，甚至得到 200 OK 响应（与我在网上找到的少数类似的错误报告形成对比），但是由于参数无效，它仍然失败。
我已经启用了详细调试，正如您从输出中看到的那样，但我 none 更聪明。在托管跑步者的框中查看 Windows 事件日志中的 GitLab 跑步者条目也不会阐明任何事情。工件的总大小为 61.1MB，因此我认为我的问题与此无关。
谁能从这个输出中看出什么是无效的？我可以确定哪个参数无效 and/or 为什么它无效？
编辑：我尝试过的事情
- 为
artifacts:expire_in. 指定一个值
- 将
artifacts:public设置为 FALSE，因为我使用的是自托管 GitLab 环境和 the default value for this setting (TRUE) is not valid in such an environment。 - 尝试我能想到的每一种格式来获取
artifacts:paths设置的值（这似乎非常可靠 - 无论我使用哪种格式，Runner 似乎都可以毫无问题地解析它并找到要上传的文件）。 - 从
stages:
- build
build-job:
variables:
CI_DEBUG_TRACE: "true"
stage: build
script:
- echo "Test" > test.txt
artifacts:
paths:
- test.txt
这项工作大约有 50% 的时间在上传工件时挂起，我不得不取消它。另一半时间它以与我之前的项目完全相同的方式失败：
经过无数小时的努力，最终问题似乎是我们的内部 Web 应用程序防火墙阻止了将工件传输到服务器或从服务器返回的响应的某些部分。将 WAF 重新配置为不阻止来自机器 运行 GitLab Runner 的流量，工件已成功上传并且作业成功。
如果来自 GitLab 的日志记录更好，这将更容易诊断。根据我对 this issue 的评论，即使响应代码为 200.
奇怪的是 - 并且使问题的诊断更加困难 - 当我与我们的 GitLab 实例的管理员一起解决问题，挖掘日志并 运行 它处于调试模式时，工件上传过程是 上传内容成功。例如，我们可以看到 GitLab Runner 的日志已经上传到服务器。很明显，WAF 的阻塞是有选择性的，并没有双向阻塞。