Question

我想自动将我的Gitlab存储库中的新工作部署到生产服务器上运行的实时网站。实时网站是live分支的GIT repo克隆。

我的问题：

每次“构建”发生时，跑步者似乎重新克隆我的回复，进入~/builds/...。这是强制性行为吗？我认为我真正想要的只是我的生产网站目录中的git pull。
如果真的每次都要克隆回购，为什么不呢git reset呢？至少那会随着时间的推移节省大量的带宽，不是吗？
如何运行存储库根目录中的deploy.sh？我目前在我的gitlab.com构建信息中收到此错误：bash: line 23: deploy.sh: command not found

我的.gitlab-ci.yml文件：

deploy_to_production:
  script:
    - deploy.sh
  only:
    - live
  tags:
    - prod

详细信息

为此，我想在生产服务器上运行一个简单的shell脚本（deploy.sh），每当我推送到我的仓库（live分支的特定分支时，我的情况）。这个shell脚本与我的.gitlab-ci.yml一起位于我的GIT存储库中。

该脚本基本上只执行git reset，fetch和pull，使生产版本与存储库中的内容保持同步。

我已经在我的服务器上安装了一个“shell”多跑步者，并将其连接到gitlab.com，在那里我可以看到它处于活动状态。

总的来说，我正在咆哮错误的树？我应该更改我的deploy.sh，以便它不会对新工作进行git checkout，而是使用cp或rsync从~/builds/...移动新代码进入制作网站？

Answer 1

问：克隆是强制性行为吗？

据我所知，这是因为假设在构建过程中你使用代码。

如果那不是你的情况而且你只想“告诉生产服务器”从你的仓库中提取代码，那么也许你可以采取不同的方法并使用webhook代替。 GitLab会向您的服务器发出HTTP请求，并以JSON格式传递有关事件（推送，合并等）的信息。接收脚本然后会解析它并决定是否执行git pull。

如果在部署之前在构建过程中对代码执行了其他任务，那么是，更改策略并使用运行程序已经为您检出的代码。我可能会尝试以某种方式进行 atomic 更改（rsyncing到live目录会使你的应用程序在运行时处于某种不确定的状态，如果由于某种原因而导致其崩溃），例如将实时代码放在符号链接的目录中。然后，部署脚本会将新代码目录复制到其最终目标，进行必要的调整并将符号链接的目标从旧的实时目录更改为新目录。

问：如果每次真的必须克隆回购，为什么不重置它呢？

这对开发者来说更是一个问题。别人的回答只是猜测。

问：如何运行存储库根目录中的deploy.sh？

如果 deploy.sh 脚本设置了可执行位，则使用./deploy.sh，否则使用bash deploy.sh。

如何使用Gitlab CI运行程序设置非常简单的部署？

详细信息

1 个答案: