自动部署系统

lddfg · 2025 年2 月 18 日 16:51

Gitea/Gogs

软件介绍

Gogs

Gogs是一种极易建造的自助Git服务。

主要特性

控制面板，用户页面以及活动时间线
通过SSH，HTTP和HTTPS协议操作仓库
管理用户，组织和仓库
仓库和组织级Webhook，包括Slack，Discord和钉钉
仓库Git钩子，部署密钥和Git LFS
仓库工单（Issue），合并请求（Pull Request），Wiki，保护分支和多人协作
从其他代码平台迁移和永久仓库以及Wiki
在线编辑仓库文件和Wiki
Jupyter笔记本和PDF的渲染
通过SMTP，LDAP，反向代理，GitHub.com和GitHub企业版进行用户认证
开启两步验证（2FA）登录
自定义HTML模板，静态文件和许多其他组件
多样的数据库架构，包括PostgreSQL，MySQL，SQLite3等
多种语言本地化

Gitea

Gitea是Gogs的修改版本，和Gogs功能类似，这链接是关于其功能对比。

自动化设置

两个软件都提供管理员通过web界面设置项目的Git服务器钩子。这里通过Gitea设置来介绍，Gogs设置也差不多。

在创建项目之后，进入项目主页，在项目描述的右上方点击进入仓库设置。

在仓库设置页面，有管理Git钩子标签，里面有三个钩子可进行配置：pre-receive、update、post-receive 。自动部署由于是在提交之后进行更新部署，所以使用第三个钩子。这里是关于各个钩子的详细介绍。

点击post-receive右边的修改图标对脚本进行修改

脚本使用ruoy项目自动部署项目作为说明，可作为参考。脚本中命令行执行的输出，都会定向回client ，所以在你push之后，可能会等待一段时间(服务器执行完脚本)，并打印出相关信息。

#!/bin/bash
function deploy(){
  # ====== 参数说明 ======
  # 第一个参数为仓库URI
  # 第二个参数为部署分支
  # 第三个参数为仓库目录
  # 第四个参数为jar部署目录
  # 第五个参数为js部署目录
  # =====================
  # 设置环境变量
  NODE_HOME=/opt/node
  NODE_PATH=$NODE_HOME/lib/node_modules
  M2_HOME=/opt/maven
  JAVA_HOME=/opt/jdk
  JRE_HOME=$JAVA_HOME/jre
  PATH=$PATH:$JAVA_HOME/bin:$M2_HOME/bin:/usr/local/mysql/bin:$NODE_HOME/bin
  CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
  export NODE_HOME
  export NODE_PATH
  export JAVA_HOME
  export JRE_HOME
  export PATH
  export CLASSPATH
  # 克隆Release最新代码
  if [ ! -d "$3" ]; then
    mkdir -p "$3"
  fi
  cd "$3"
  if [ "`ls . | wc -w`" -gt "0" ]; then
    unset $(git rev-parse --local-env-vars)
    git pull > /dev/null
  else
    git clone -b "$2" "$1" ./ > /dev/null
  fi
  # 后端部署
  mvn clean package -Dmaven.test.skip=true > /dev/null
  if [ $? -ne 0 ]; then
    echo "======== 后端构建失败 ========"
    return 1
  fi
  sudo systemctl stop ruoyibackend.service > /dev/null
  cp ruoyi-admin/target/ruoyi-admin.jar "$4"
  sudo systemctl start ruoyibackend.service > /dev/null
  echo "======== 后端部署完成 ========"
  # 前端部署
  cd ruoyi-ui
  npm install --registry=https://registry.npm.taobao.org > /dev/null
  if [ $? -ne 0 ]; then
    echo "======== 前端 npm install 失败 ========"
    return 1
  fi
  npm run build:prod > /dev/null
  if [ $? -ne 0 ]; then
    echo "======== 前端构建失败 ========"
    return 1
  fi
  cp -rfp dist/* "$5"
  echo "======== 前端部署完成 ========"
  return 0
}

while read oldrev newrev refname
do
  branch=$(git rev-parse --symbolic --abbrev-ref $refname)  # 不使用该环境变量设定的目录
  if [ "Release" == "$branch" ]; then
    deploy /path/to/uri.git $branch /path/to/build /path/to/backend /path/to/web-design
    if [ $? -ne 0 ]; then
      echo "======== 自动化部署失败,请查看相关日志 ========"
      return 1
    else
      echo "======== 自动化部署成功，玩的开心。 ========"
    fi
  fi
done

脚本运行的用户为运行gitea服务的用户，我这使用非root用户运行，所以有些需要特权的命令都加了sudo命令，以使用特权身份运行。至于为什么无需密码就能sudo执行命令，是因为我设置了sudoers。

git命令

这里模拟从克隆仓库，编写代码，提交到部署，介绍途中会用到的git命令，以供参考(这里假设master分支为默认分支，Release分支为发布分支)

git clone uri.git  # 克隆仓库
# code code code
git add -A .
git commit -am "fix fix fix"
git push
# 达到发布要求
git checkout Release  # 检出`Release`分支
git merge master  # 快进到`master`
git push  # push `Release`分支到服务器`Release` 这时，服务器会进行自动打包部署，部署情况会在后面发送回服务器(注: 打包错误不会阻碍分支推送)
# 至此，自动部署完成
git checkout master # 注意，切回`master`分支
# 当然，方法不能穷尽。酌情使用

lddfg · 2025 年2 月 18 日 16:56

GIT 钩子

简介

和其它版本控制系统一样，Git能在特定的重要动作发生时触发自定义脚本

有两组这样的钩子:

客户端钩子：由诸如提交和合并这样的操作所调用
服务器端钩子：作用于诸如接收被推送的提交这样的操作

使用钩子

钩子都被存储在Git目录下的hooks子目录中。也即绝大部分项目中的.git/hooks。当你用git init初始化一个新版本库时，Git默认会在这个目录中放置一些示例脚本。这些脚本除了本身可以被调用外，它们还透露了被触发时所传入的参数。所有的示例都是shell脚本，其中一些还混杂了Perl代码，不过，任何正确命名的可执行脚本都可以正常使用。你可以用Ruby或Python或任何你熟悉的语言编写它们。这些示例的名字都是以.sample结尾，如果你想启用它们，得先移除这个后缀。

把一个正确命名(不带扩展名)且可执行的文件放入.git目录下的hooks子目录中，即可激活该钩子脚本。这样一来，它就能被Git调用。接下来，介绍常用的钩子脚本类型。

需要注意的是，克隆某个版本库时，它的客户端钩子并不随同复制。如果需要靠这些脚本来强制维持某种策略，建议你在服务器端实现这一功能。

钩子类型

客户端钩子

提交工作流钩子：前四个钩子涉及提交的过程
- pre-commit 钩子在键入提交信息前运行。它用于检查即将提交的快照，例如，检查是否有所遗漏，确保测试运行，以及核查代码。如果该钩子以非零值退出，Git将放弃此次提交，不过你可以用git commit --no-verify来绕过这个环节。你可以利用该钩子，来检查代码风格是否一致(运行类似lint的程序)、尾随空白字符是否存在(自带的钩子就是这么做的)，或新方法的文档是否适当。
- prepare-commit-msg 钩子在启动提交信息编辑器之前，默认信息被创建之后运行。它允许你编辑提交者所看到的默认信息。该钩子接收一些选项：存有当前提交信息的文件的路径、提交类型和修补提交的提交的SHA-1校验。它对一般的提交来说并没有什么用；然而对那些会自动产生默认信息的提交，如提交信息模板、合并提交、压缩提交和修订提交等非常实用。你可以结合提交模板来使用它，动态地插入信息。
- commit-msg 钩子接收一个参数，此参数即上文提到的，存有当前提交信息的临时文件的路径。如果该钩子脚本以非零值退出，Git将放弃提交，因此，可以用来在提交通过前验证项目状态或提交信息。
- post-commit 钩子在整个提交过程完成后运行。它不接收任何参数，但你可以很容易地通过运行git log -1 HEAD来获得最后一次的提交信息。该钩子一般用于通知之类的事情。
电子邮件工作流钩子：你可以给电子邮件工作流设置三个客户端钩子。它们都是由git am命令调用的。如果你需要通过电子邮件接收由git format-patch产生的补丁，这些钩子也许用得上。
- 第一个运行的钩子是applypatch-msg。它接收单个参数：包含请求合并信息的临时文件的名字。如果脚本返回非零值，Git将放弃该补丁。你可以用该脚本来确保提交信息符合格式，或直接用脚本修正格式错误。
- 下一个在git am运行期间被调用的是pre-applypatch。它正好运行于应用补丁之后，产生提交之前，所以你可以用它在提交前检查快照。你可以用这个脚本运行测试或检查工作区。如果有什么遗漏，或测试未能通过，脚本会以非零值退出，中断git am的运行，这样补丁就不会被提交。
- post-applypatch 运行于提交产生之后，是在git am运行期间最后被调用的钩子。你可以用它把结果通知给一个小组或所拉取的补丁的作者。但你没办法用它停止打补丁的过程。
其它客户端钩子
- pre-rebase 钩子运行于变基之前，以非零值退出可以中止变基的过程。你可以使用这个钩子来禁止对已经推送的提交变基。Git自带的pre-rebase钩子示例就是这么做的，不过它所做的一些假设可能与你的工作流程不匹配。
- post-rewrite 钩子被那些会替换提交记录的命令调用，比如git commit --amend和git rebase(不过不包括git filter-branch)。它唯一的参数是触发重写的命令名，同时从标准输入中接受一系列重写的提交记录。这个钩子的用途很大程度上跟post-checkout和post-merge差不多。
- 在git checkout成功运行后，post-checkout钩子会被调用。你可以根据你的项目环境用它调整你的工作目录。其中包括放入大的二进制文件、自动生成文档或进行其他类似这样的操作。
- 在git merge成功运行后，post-merge钩子会被调用。你可以用它恢复Git无法跟踪的工作区数据，比如权限数据。这个钩子也可以用来验证某些在Git控制之外的文件是否存在，这样你就能在工作区改变时，把这些文件复制进来。
- pre-push 钩子会在git push运行期间，更新了远程引用但尚未传送对象时被调用。它接受远程分支的名字和位置作为参数，同时从标准输入中读取一系列待更新的引用。你可以在推送开始之前，用它验证对引用的更新操作(一个非零的退出码将终止推送过程)。
- Git 的一些日常操作在运行时，偶尔会调用git gc --auto进行垃圾回收。pre-auto-gc钩子会在垃圾回收开始之前被调用，可以用它来提醒你现在要回收垃圾了，或者依情形判断是否要中断回收。

服务器钩子

除了客户端钩子，作为系统管理员，你还可以使用若干服务器端的钩子对项目强制执行各种类型的策略。这些钩子脚本在推送到服务器之前和之后运行。推送到服务器前运行的钩子可以在任何时候以非零值退出，拒绝推送并给客户端返回错误消息，还可以依你所想设置足够复杂的推送策略。

pre-receive 处理来自客户端的推送操作时，最先被调用的脚本是该脚本。它可以从标准输入获取更新的所有分支的oldrev, newrev, refname列表。如果它以非零值退出，所有的推送内容都不会被接受。你可以用这个钩子阻止对引用进行非快进(non-fast-forward)的更新，或者对该推送所修改的所有引用和文件进行访问控制。
update 该脚本和pre-receive脚本十分类似，不同之处在于它会为每一个准备更新的分支各运行一次。假如推送者同时向多个分支推送内容，pre-receive只运行一次，相比之下update则会为每一个被推送的分支各运行一次。它不会从标准输入读取内容，而是接受三个参数：引用的名字(分支)，推送前的引用指向的内容的SHA-1值，以及用户准备推送的内容的SHA-1值。如果update脚本以非零值退出，只有相应的那一个引用会被拒绝；其余的依然会被更新。
post-receive 该挂钩在整个过程完结以后运行，可以用来更新其他系统服务或者通知用户。它接受与pre-receive相同的标准输入数据。它的用途包括给某个邮件列表发信，通知持续集成(continous integration)的服务器，或者更新问题追踪系统(ticket-tracking system) —— 甚至可以通过分析提交信息来决定某个问题(ticket)是否应该被开启，修改或者关闭。该脚本无法终止推送进程，不过客户端在它结束运行之前将保持连接状态，所以如果你想做其他操作需谨慎使用它，因为它将耗费你很长的一段时间。

使用注意

环境变量问题

在GIT的钩子中会为执行脚本配置GIT相关环境变量,比如GIT_DIR等，所以，当你在脚本中直接执行git pull时使用的并不是PWD这个目录，而是GIT_DIR这个目录。比如当你想要程序自动部署的时候，设置服务器端的post-receive钩子：

#!/bin/bash
cd /home/b/project
git pull > /dev/null 2>&1

如果你直接设置成这样，就会收到remote: fatal: Not a git repository: '.'的错误，就是因为设置了环境变量GIT_DIR。可以将脚本修改成如下：

#!/bin/bash
cd /home/b/project
unset $(git rev-parse --local-env-vars)
git pull > /dev/null 2>&1

示例

判断更新指定`tag`时更新服务器

我们在服务器上部署服务，当我们向master分支提交更新时，服务器自动部署更新脚本使用服务器post-receive钩子，脚本内容如下：

#!/bin/bash
while read oldrev newrev refname
do
    branch=$(git rev-parse --symbolic --abbrev-ref $refname)
    if [ "master" == "$branch" ]; then
        (unset $(git rev-parse --local-env-vars) && git -C /home/b/project pull > /dev/null 2>&1)
    fi
done

注意，post-receive是从标准输入读取数据，因此使用的是read，而不是$1, $2, $3等参数。