0%

使用 Gitea Actions 实现 Hexo 博客持续集成与持续部署

目录

目录-使用 Gitea Actions 实现 Hexo 博客持续集成与持续部署

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 工作流如下图所示:

典型的 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
2
sudo mv /usr/local/bin/gitea /usr/local/bin/gitea_bkp_1.17.0
sudo mv /etc/gitea/app.ini /etc/gitea/app.ini_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
2
3
sudo mv gitea-1.20.3-linux-amd64 /usr/local/bin/gitea
sudo chmod +x /usr/local/bin/gitea
sudo systemctl start gitea.service

由于我们重命名了 Gitea 配置文件,所以此时在浏览器中访问 IP:3000 或自定义域名会重新来到 Gitea 的安装界面,可参考《使用 Gitea + Git Hook 实现 Hexo 博客源码托管与持续集成》进行相关安装配置。需要注意的是,点击安装后可能会弹出类似升级安装存在潜在风险的提示,直接勾选确认并继续安装即可。

完成安装后将重新生成 Gitea 配置文件 /etc/gitea/app.ini,在配置文件末尾添加 actions 配置项并开启 Gitea Actions 功能:

1
2
[actions]
ENABLED = true

随后重启 Gitea 服务:

1
sudo systemctl restart gitea.service

2.1.4 为指定仓库开启 Actions 功能

即使 Gitea Actions 已经在配置文件中开启,对于某个指定的仓库而言其 Actions 功能仍是默认关闭的,需要针对仓库进行单独配置:

为指定仓库开启 Actions

2.2 部署 act runner

Gitea 使用 act runner 来执行具体的工作流任务,act runner 可通过下述三种方式进行部署:

  • 直接下载预构建的二进制可执行文件
  • 从源码进行构建
  • 使用 docker 镜像

本文采用第一种方式,并将其部署到与 Gitea 相同的物理机上(也可部署到不同物理机上)。

2.2.1 安装

我们新建一个工作目录专门用于 CI/CD 工作流,本文中以 ~/gitea_actions 为例:

1
2
cd ~
mkdir gitea_actions

点击这里下载 v0.2.5 版本的 act runner,将其移入 ~/gitea_actions 并为其添加可执行权限:

1
2
3
sudo mv act_runner-0.2.5-linux-amd64 ~/gitea_actions/
cd ~/gitea_actions
sudo chmod +x act_runner-0.2.5-linux-amd64

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 注册:

获取用于注册 runner 的 gitea token

图中的 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 注册过程如下图所示:

runner 的注册过程

完成注册后,将在 act runner 所在目录下生成一个名为 .runner 的文件,里面存储了 runner 的注册信息。同时,我们也将在方才获取 token 的页面看到新增了一个尚处于离线(Offline)状态的 runner,它的 name 和 labels 分别为 test_runnertest

新注册的 runner

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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
name: Blog CI & CD

on:
push:
branches:
- master

env:
BARE_REPO_DIR: /var/lib/gitea/data/gitea-repositories/shipeng/blog.git
CLONED_REPO_DIR: /var/lib/gitea/data/gitea-repositories/shipeng/blog
DEPLOYED_DIR: /var/www/blog

jobs:
build:
name: Build blog
runs-on: blog_ci_cd
steps:
- name: Clone
run: |
rm -rf $CLONED_REPO_DIR
git clone $BARE_REPO_DIR $CLONED_REPO_DIR

- name: Configure
run: |
source /usr/local/nvm/nvm.sh
nvm use 12.14.1

- name: Build
run: |
cd $CLONED_REPO_DIR
chmod -R 777 node_modules
npm run clean
npm run douban
npm run build

deploy:
name: Deploy blog
runs-on: blog_ci_cd
needs: Build blog
steps:
- name: Deploy
run: |
rm -rf $DEPLOYED_DIR/*
cp -rf $CLONED_REPO_DIR/public/* $DEPLOYED_DIR/

上述脚本定义了一个名为 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

上述工作流的示意图如下所示:

Hexo 博客 CICD 工作流示意图

正常情况下,将工作流 YAML 脚本 push 到远程云服务器的 Gitea 仓库后,将在 Gitea 的 Actions 页面看到正在运行的工作流:

正在运行的 Gitea Actions 工作流

4 后记

类似于 GitHub Actions,Gitea Acitons 是 Gitea 的内置 CI/CD 解决方案。本文从基本概念入手,简要介绍了通过 Gitea Actions 实现 Hexo 博客 CI/CD 的基本流程。

笔者已将 Gitea Actions 应用到了生产环境中,用于智能驾驶算法应用层中某融合算法模块的持续集成,目前体验良好。

参考

  1. 使用 Gitea + Git Hook 实现 Hexo 博客源码托管与持续集成
  2. GitHub Actions 文档
  3. Gitea Actions
  4. Upgrade from an old Gitea
  5. Gitea Actions Quick Start
  6. Act Runner
  7. GitHub Actions 的工作流语法

Thank you for your donate!