git - 如何使用 Gitlab CI 运行器设置非常简单的部署？

Question

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

我的问题:

• 每次“构建”发生时，运行程序似乎都会将我的存储库重新克隆到 ~/builds/... 中。这是强制行为吗？我想我真正想要的是我的生产网站目录中的 git pull。

• 如果它真的每次都必须克隆 repo，为什么不 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 格式传递有关事件(推送、 merge 等)的信息。然后接收脚本会解析它并决定是否执行 git pull。

如果您在部署前的构建过程中确实有其他任务要对代码执行，那么是的，改变策略并使用运行器已经为您 check out 的代码。我可能会尝试以某种方式更改 atomic (rsyncing 到实时目录会使您的应用程序在运行时处于某种不确定状态，如果由于某种原因而失败则处于困惑状态)，例如通过将实时代码放在符号链接(symbolic link)的目录中。然后，部署脚本会将新代码目录复制到其最终目的地，进行任何必要的调整并将符号链接(symbolic link)的目标从旧的事件目录更改为新的目录。

问:如果真的每次都要克隆 repo，为什么不 git reset 呢？

这对开发人员来说更像是一个问题。任何其他人的回答都只是猜测。

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

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