CICD

CI/CD 是持续集成和持续交付/部署的缩写,旨在简化并加快软件开发生命周期。

持续集成(CI)是指自动且频繁地将代码更改集成到共享源代码存储库中的做法。持续交付和/或持续部署(CD)是一个由两部分组成的过程,涉及代码更改的集成、测试和交付。持续交付不会自动部署到生产环境,持续部署则会自动将更新发布到生产环境。
使用gitea-action实现CICD-2024-12-25-13-21-32

简单来说,就是我们将代码提交到远程仓库后,自动化服务会替我们完成测试交付和部署的功能。

常用的CICD工具

使用gitea-action实现CICD-2024-12-25-16-34-09
使用gitea-action实现CICD-2024-12-25-13-23-42
在本文中我将演示使用gitea actions实现hexo的自动部署功能。

正片开始

正如其名,其实gitea和github actions的功能几乎一致,就是沿用下来了而已。
在我们的操作过程中,主要有三步:

  1. 使用docker启动一个act_runner,作为action的服务器
  2. 配置deploy.yml实现推送时,自动部署到服务器
  3. 使用nginx展示部署后的页面

安装act_runner

打开gitea的官方文档可以查阅关于act_runner的配置信息

注册runner

在运行Act Runner之前,需要进行注册,因为Runner需要知道从哪里获取Job,并且对于Gitea实例来说,识别Runner也很重要。

Runner级别
您可以在不同级别上注册Runner,它可以是:

实例级别:Runner将为实例中的所有存储库运行Job。
组织级别:Runner将为组织中的所有存储库运行Job。
存储库级别:Runner将为其所属的存储库运行Job。
请注意,即使存储库具有自己的存储库级别Runner,它仍然可以使用实例级别或组织级别Runner。未来的版本可能提供更多对此进行更好控制的选项。

获取注册令牌
Runner级别决定了从哪里获取注册令牌。

实例级别:管理员设置页面,例如 <your_gitea.com>/admin/actions/runners
组织级别:组织设置页面,例如 <your_gitea.com>/<org>/settings/actions/runners
存储库级别:存储库设置页面,例如 <your_gitea.com>/<owner>/<repo>/settings/actions/runners

启动runner

我这里直接使用docker compose启动一个。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
version: "3.8"

services:
runner:
image: gitea/act_runner:latest
container_name: act_runner
environment:
CONFIG_FILE: /config.yaml
GITEA_INSTANCE_URL: "${INSTANCE_URL}"
GITEA_RUNNER_REGISTRATION_TOKEN: "${REGISTRATION_TOKEN}"
GITEA_RUNNER_NAME: "${RUNNER_NAME}"
GITEA_RUNNER_LABELS: "${RUNNER_LABELS}"
volumes:
- ./config.yaml:/config.yaml
- ./data:/data
- /var/run/docker.sock:/var/run/docker.sock
restart: always

然后你就可以看到你这边已经存在了一个全局的runner可以提供使用了
使用gitea-action实现CICD-2024-12-25-13-45-09

添加配置文件

在你的仓库下面创建一个.gitea/workflows的文件夹。在文件夹下任意创建一个yml配置文件,如下所示:
使用gitea-action实现CICD-2024-12-25-13-47-16
具体代码如下:

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
45
46
47
48
49
50
name: Deploy Hexo Blog

on:
push:
branches:
- main # 或你希望触发部署的分支

jobs:
deploy:
runs-on: ubuntu-latest

steps:
- name: Checkout Code
uses: actions/checkout@v2

- name: Setup Node.js
uses: actions/setup-node@v2
with:
node-version: '16' # 请根据你的需求选择 Node.js 版本

- name: Install Dependencies
run: |
npm install
npm install hexo-cli -g
- name: Build Hexo
run: hexo generate

- name: Deploy to Server
env:
SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
SERVER_USER: ${{ secrets.SERVER_USER }}
SERVER_HOST: ${{ secrets.SERVER_HOST }}
SERVER_PATH: ${{ secrets.SERVER_PATH }}
run: |
# 设置 SSH 密钥
mkdir -p ~/.ssh
echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa

# 使用 scp 将 public 目录推送到服务器指定路径
scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -r ./public/* $SERVER_USER@$SERVER_HOST:$SERVER_PATH


# 如果你需要删除多余的文件,可以在此添加其他命令来清理旧的内容
ssh -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_HOST <<EOF
# 进入服务器指定目录
cd $SERVER_PATH
# 可以在此进行其他操作,如清理过时的文件或配置
echo "Deployment complete"
EOF

上述代码基本与github actions的语法一致,这里不提供相关的基础概念了。想学习的可以查阅github的官网。(大部分情况下可以通过gpt等ai生成一个样例模板,再自己去写所需要的部分)

上面代码中个别细节需要提及:

  1. secrets.SSH_PRIVATE_KEY等密钥配置文件是保存在仓库的如下选项中
    这与github中的配置也是相似的
    使用gitea-action实现CICD-2024-12-25-13-51-03
  2. StrictHostKeyChecking=no用于关闭交互服务(一般使用ssh密钥连接时都是交互式会提示是否接受等概念)
    使用gitea-action实现CICD-2024-12-25-13-52-32

nginx页面展示

也就是你所看到的博客页面啦。这些都是我通过nginx展示出来的。不过关于nginx的具体代码配置我就不在此展开了。我应该会有另外的文章去说明这部分内容。