0

经过一些调试和反馈后，我确定post-receiveGitLab 服务器中的脚本在 60 秒后（大约 ~+- 2 秒）终止。helper.sh我想我可以通过创建另一个由脚本调用一次的脚本来规避这个问题post-receive，但是helper.sh脚本仍然被终止（以及post-receivescript.

一旦4:Deadline Exceeded.消息在我按下“提交”的页面上的 GitLab 服务器中弹出，就会终止： 在此处输入图像描述

这似乎表明我没有为我的目标使用正确的工具*，或者我对 GitLab 如何管理post-receive工作缺乏一些了解。我是否应该使用作业以外的东西post-receive来运行一些脚本 * 来获取提交的构建状态，然后处理该数据？或者我可以post-receive在 GitLab 服务器中找到作业的此时间限制设置吗？

笔记

似乎GitLab 应用程序限制可能与此处相关，我将尝试对其进行修改，然后查看post-receive脚本可以运行的持续时间是否延长。

gitlab.rb在yielded中进一步查看这些设置：

### Request duration
###! Tells the rails application how long it has to complete a request
###! This value needs to be lower than the worker timeout set in unicorn/puma.
###! By default, we'll allow 95% of the the worker timeout
# gitlab_rails['max_request_duration_seconds'] = 57

这似乎与post-receive允许脚本运行的实际持续时间更接近。

尝试

由于我希望post-receive脚本至少运行 10 分钟，因此我尝试增加/etc/gitlab/gitlab.rb文件中的工作人员限制。特别是，我尝试（独立和组合）添加以下更改：

gitlab_rails['max_request_duration_seconds'] = 570
gitlab_rails['env'] = {
   'GITLAB_RAILS_RACK_TIMEOUT' => 600
 }
gitlab_rails['application_settings_cache_seconds'] = 600
puma['worker_timeout'] = 600

其次是：

gitlab-ctl reconfigure
gitlab-ctl restart

但是，post-receive脚本在 54 秒后仍然被切断。

4

0 回答 0