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
,该过程也会失败。这是日志输出:
因此,它找到工件,尝试上传它们,甚至获得响应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% 的时间,这项工作会因工件上传而挂起,我必须取消它。另一半时间它会以与我之前的项目完全相同的方式失败:
经过无数个小时的研究,似乎最终的问题是我们的内部 Web 应用程序防火墙阻止了将工件传输到服务器的某些部分,或者阻止了从服务器返回的响应。将 WAF 重新配置为不阻止来自运行 GitLab Runner 的计算机的流量后,工件将成功上传,作业也会成功。
如果 GitLab 的日志记录更好的话,诊断起来会容易得多。根据我对此问题的评论,上传工件后应该可以看到来自 GitLab 服务器的响应内容,即使响应代码是200
.
奇怪的是,当我与 GitLab 实例的管理员一起解决问题、挖掘日志并在调试模式下运行它时,工件上传过程正在成功上传某些内容,这使得诊断问题变得更加困难。例如,我们可以看到 GitLab Runner 的日志已上传到服务器。显然,WAF 的阻止是有选择性的,并没有阻止两个方向上的所有内容。
归档时间: |
|
查看次数: |
3932 次 |
最近记录: |