使用gitea action实现CICD
CICD
CI/CD 是持续集成和持续交付/部署的缩写,旨在简化并加快软件开发生命周期。
持续集成(CI)是指自动且频繁地将代码更改集成到共享源代码存储库中的做法。持续交付和/或持续部署(CD)是一个由两部分组成的过程,涉及代码更改的集成、测试和交付。持续交付不会自动部署到生产环境,持续部署则会自动将更新发布到生产环境。
简单来说,就是我们将代码提交到远程仓库后,自动化服务会替我们完成测试交付和部署的功能。
常用的CICD工具
在本文中我将演示使用gitea actions
实现hexo的自动部署功能。
正片开始
正如其名,其实gitea和github actions的功能几乎一致,就是沿用下来了而已。
在我们的操作过程中,主要有三步:
- 使用docker启动一个act_runner,作为action的服务器
- 配置
deploy.yml
实现推送时,自动部署到服务器 - 使用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 | version: "3.8" |
然后你就可以看到你这边已经存在了一个全局的runner
可以提供使用了
添加配置文件
在你的仓库下面创建一个.gitea/workflows
的文件夹。在文件夹下任意创建一个yml
配置文件,如下所示:
具体代码如下:
1 | name: Deploy Hexo Blog |
上述代码基本与github actions的语法一致,这里不提供相关的基础概念了。想学习的可以查阅github的官网。(大部分情况下可以通过gpt等ai生成一个样例模板,再自己去写所需要的部分)
上面代码中个别细节需要提及:
secrets.SSH_PRIVATE_KEY
等密钥配置文件是保存在仓库的如下选项中
这与github中的配置也是相似的
StrictHostKeyChecking=no
用于关闭交互服务(一般使用ssh密钥连接时都是交互式会提示是否接受等概念)
nginx页面展示
也就是你所看到的博客页面啦。这些都是我通过nginx展示出来的。不过关于nginx的具体代码配置我就不在此展开了。我应该会有另外的文章去说明这部分内容。