目录
0 前言
在此前的文章《使用 Gitea + Git Hook 实现 Hexo 博客源码托管与持续集成》中,我们介绍了如何使用 Gitea v1.17.0 进行 Hexo 博客的源码托管,并借助 Git Hook 实现博客的持续集成(Continuous Integratgion,CI)和持续部署(Continuous Deployment,CD)。
Gitea 自 v1.19.0 版本起引入了类似于 GitHub Actions 的内置 CI/CD 解决方案 Gitea Actions。本文将从基本概念入手,简要介绍如何通过 Gitea Actions 功能更优雅地实现 Hexo 博客的 CI/CD。
1 基本概念
类似于 GitHub Actions,Gitea Actions 同样包含了工作流(Workflow)、事件(Event)、任务(Job)、步骤(Step)、运行器(Runner)等几项重要的基本概念。
1.1 工作流
工作流是一个可配置的自动化过程。我们将本地写好的 Markdown 文件推送(push
)到远程云服务器的 Gitea 仓库,触发后续 Markdown 向 HTML 页面的自动渲染及博客站点的自动发布更新,这个过程就是一个典型的工作流。
工作流由定义在仓库指定目录下的 YAML 脚本描述,对于 GitHub Actions 而言,这个目录是 .github/workflows
,对于 Gitea Actions 而言,这个目录是 .gitea/workflows
。
1.2 事件
事件是触发工作流开始运行的源头,仍以 Hexo 博客的 CI/CD 工作流为例,我们将 Markdown 文件 push
到远程云服务器 Gitea 仓库的动作就是一个事件。
1.3 任务和步骤
任务是工作流中一组步骤的集合,一个工作流可以包含多个任务,一个任务可以包含多个步骤,每个步骤都包含了若干条具体的操作命令。步骤按顺序执行,并且相互依赖。
我们可以配置工作流中任务间的依赖关系(默认无依赖关系,并行运行),当一个任务依赖于另一个任务时,它将等待所依赖任务完成后才能开始运行。
1.4 运行器
运行器是执行工作流任务的软件程序,工作流中的每个任务都需要指定运行器,不同的任务可以指定不同的运行器。
一个典型的 Gitea Actions 工作流如下图所示:
2 环境配置
2.1 安装 Gitea v1.20.3
本文中使用的 Gitea 版本是 v1.20.3,Gitea 的从零安装可直接参考《使用 Gitea + Git Hook 实现 Hexo 博客源码托管与持续集成》中的相应章节。由于此前我们已经安装了 v1.17.0 版本,所以这里我们需要解决的是如何将 Gitea 由 v1.17.0 升级到 v1.20.3。
关于 Gitea 的版本升级,官方提供了多种方式,这里我们选择二进制的升级方式,升级步骤下面逐一展开。
2.1.1 停止 Gitea 服务
1 | sudo systemctl stop gitea.service |
2.1.2 备份可执行文件与配置文件
1 | sudo mv /usr/local/bin/gitea /usr/local/bin/gitea_bkp_1.17.0 |
官方指导中还建议备份数据库以及配置文件中 APP_DATA_PATH
参数指定路径下的数据文件,但笔者在实际操作中并未实施该建议也同样运行正常。读者若担心数据安全,可在备份了可执行文件和配置文件的基础上,再将 Gitea 安装目录进行完整备份:
1 | sudo cp -r /var/lib/gitea /var/lib/gitea_bkp_1.17.0 |
2.1.3 重新安装并配置 Gitea
下载 Linux 环境下的 Gitea v1.20.3 可执行文件,将其移动至 /usr/local/bin
路径下并重命名为 gitea
,随后为其添加可执行权限并启动 Gitea 服务:
1 | sudo mv gitea-1.20.3-linux-amd64 /usr/local/bin/gitea |
由于我们重命名了 Gitea 配置文件,所以此时在浏览器中访问 IP:3000
或自定义域名会重新来到 Gitea 的安装界面,可参考《使用 Gitea + Git Hook 实现 Hexo 博客源码托管与持续集成》进行相关安装配置。需要注意的是,点击安装后可能会弹出类似升级安装存在潜在风险的提示,直接勾选确认并继续安装即可。
完成安装后将重新生成 Gitea 配置文件 /etc/gitea/app.ini
,在配置文件末尾添加 actions
配置项并开启 Gitea Actions 功能:
1 | [actions] |
随后重启 Gitea 服务:
1 | sudo systemctl restart gitea.service |
2.1.4 为指定仓库开启 Actions 功能
即使 Gitea Actions 已经在配置文件中开启,对于某个指定的仓库而言其 Actions 功能仍是默认关闭的,需要针对仓库进行单独配置:
2.2 部署 act runner
Gitea 使用 act runner 来执行具体的工作流任务,act runner 可通过下述三种方式进行部署:
- 直接下载预构建的二进制可执行文件
- 从源码进行构建
- 使用 docker 镜像
本文采用第一种方式,并将其部署到与 Gitea 相同的物理机上(也可部署到不同物理机上)。
2.2.1 安装
我们新建一个工作目录专门用于 CI/CD 工作流,本文中以 ~/gitea_actions
为例:
1 | cd ~ |
点击这里下载 v0.2.5 版本的 act runner,将其移入 ~/gitea_actions
并为其添加可执行权限:
1 | sudo mv act_runner-0.2.5-linux-amd64 ~/gitea_actions/ |
2.2.2 配置
act runner 使用 YAML 配置文件进行配置,我们可以通过下述命令来生成配置文件:
1 | ./act_runner-0.2.5-linux-amd64 generate-config > config.yaml |
act runner 的默认配置将被写入 config.yaml
,随后我们可以对配置文件进行自定义修改,并在执行任何命令时指定配置文件:
1 | ./act_runner-0.2.5-linux-amd64 --config config.yaml [command] |
未指定配置文件时,act runner 将使用默认配置。
2.2.3 注册
在运行 act runner 前,我们需要完成从 runner 到 Gitea 的注册过程:
1 | ./act_runner-0.2.5-linux-amd64 --config config.yaml register |
执行上述命令后,act runner 将要求我们依次提供如下信息:
1)Gitea 实例的 URL
我们的 Gitea 搭建在阿里云服务器上,这里的 URL 指代的是:
1 | http://云服务器公网IP:3000 |
我们可以通过 ifconfig
命令查看云服务器公网 IP。
2)runner token
token 用于 Gitea 和 runner 间的相互认证,可按照下图所示的步骤获取 token 用于 runner 注册:
图中的 blog_ci_cd
是笔者此前已创建好的用于博客 CI/CD 工作流的 runner,可以看到它目前处于空闲(Idle)状态。需要注意的是,每个 token 只能用于一次注册,不能多次使用。
3)runner name
runner 的名称,若留空得话将使用主机名。
4)runner labels
runner 的标签,是个以逗号分隔开的列表,工作流的 YAML 描述文件通过 runner labels 为任务分配 runner。runner labels 若留空得话将使用默认值:
1 | ubuntu-latest:docker://node:16-bullseye,ubuntu-22.04:docker://node:16-bullseye,ubuntu-20.04:docker://node:16-bullseye,ubuntu-18.04:docker://node:16-buster |
典型的 runner 注册过程如下图所示:
完成注册后,将在 act runner 所在目录下生成一个名为 .runner
的文件,里面存储了 runner 的注册信息。同时,我们也将在方才获取 token 的页面看到新增了一个尚处于离线(Offline)状态的 runner,它的 name 和 labels 分别为 test_runner
和 test
:
2.2.4 运行
经过注册的 runner 只是建立了与 Gitea 实例间的联系,还无法运行工作流任务,我们还需要通过运行 act runner 可执行程序来唤醒它:
1 | nohup act_runner-0.2.5-linux-amd64 >/dev/null 2>&1 & |
这里我们指定 act_runner-0.2.5-linux-amd64
无挂起地在后台运行,并忽略了标准输出和错误输出。再次查看方才注册的 runner,会发现它的运行状态已由 Offline 变为 Idle,表示 runner 已被唤醒,随时可以执行工作流任务。
3 编写工作流 YAML 脚本
完成环境配置后,我们需要做的是在仓库根目录下创建 .gitea/workflows
目录,在该目录下编写工作流 YAML 脚本并 push
到远程云服务器的 Gitea 仓库。下面是笔者编写的 Hexo 博客 CI/CD 工作流 YAML 脚本 .gitea/workflows/ci-cd.yml
:
1 | name: Blog CI & CD |
上述脚本定义了一个名为 Blog CI & CD 的工作流,由发生在 master
分支上的 push
事件触发(on
关键字、push
关键字和 branches
关键字指定)。该工作流包含了两个任务(jobs
关键字指定):
- build 任务,别名 Build blog。包含三个步骤:
- Clone
- Configure
- Build
- deploy 任务,别名 Deploy blog,依赖于 Build blog(
needs
关键字指定)。只包含一个步骤:- Deploy
两个任务都通过 runs-on
关键字指定由 labels 被注册为 blog_ci_cd
的 runner 运行,每个任务所包含的步骤通过 steps
关键字指定,每个步骤所要执行的操作命令通过 run
关键字指定(分隔符 |
表示多行命令,单行命令时可省略),env
关键字则指定了工作流中的全局环境变量。完整的工作流 YAML 语法详见参考 7。
上述工作流的示意图如下所示:
正常情况下,将工作流 YAML 脚本 push
到远程云服务器的 Gitea 仓库后,将在 Gitea 的 Actions 页面看到正在运行的工作流:
4 后记
类似于 GitHub Actions,Gitea Acitons 是 Gitea 的内置 CI/CD 解决方案。本文从基本概念入手,简要介绍了通过 Gitea Actions 实现 Hexo 博客 CI/CD 的基本流程。
笔者已将 Gitea Actions 应用到了生产环境中,用于智能驾驶算法应用层中某融合算法模块的持续集成,目前体验良好。
参考
- 使用 Gitea + Git Hook 实现 Hexo 博客源码托管与持续集成
- GitHub Actions 文档
- Gitea Actions
- Upgrade from an old Gitea
- Gitea Actions Quick Start
- Act Runner
- GitHub Actions 的工作流语法