一、GitHub Actions介绍
- 持续集成由很多操作组成,比如抓取代码、运行测试、登录远程服务器,发布到第三方服务等等。
GitHub把这些操作就称为actions。 - 如果你需要某个
action,不必自己写复杂的脚本,直接引用他人写好的 action 即可,整个持续集成过程,就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方
GitHub 做了一个官方市场,可以搜索到他人提交的 actions。另外,还有一个 awesome actions 的仓库,也可以找到不少
action

- 上面说了,每个
action就是一个独立脚本,因此可以做成代码仓库,使用userName/repoName的语法引用action。比如,actions/setup-node就表示github.com/actions/setup-node这个仓库,它代表一个action,作用是安装 Node.js。事实上,GitHub 官方的actions都放在github.com/actions里面。
既然
actions是代码仓库,当然就有版本的概念,用户可以引用某个具体版本的 action。下面都是合法的 action 引用,用的就是 Git 的指针概念
actions/setup-node@74bc508 # 指向一个 commit |
1.1 概念
GitHub Actions 有一些自己的术语。
workflow(工作流程):持续集成一次运行的过程,就是一个workflow。job(任务):一个workflow由一个或多个jobs构成,含义是一次持续集成的运行,可以完成多个任务。step(步骤):每个job由多个step构成,一步步完成。action(动作):每个step可以依次执行一个或多个命令(action)
1.2 workflow 文件
GitHub Actions的配置文件叫做workflow文件,存放在代码仓库的.github/workflows目录。
workflow文件采用YAML格式,文件名可以任意取,但是后缀名统一为.yml,比如foo.yml。一个库可以有多个workflow文件。GitHub 只要发现.github/workflows目录里面有.yml文件,就会自动运行该文件。workflow文件的配置字段非常多,详见官方文档。下面是一些基本字段。
1. name
name字段是workflow的名称。如果省略该字段,默认为当前workflow的文件名。
name: GitHub Actions Demo |
2. on
on字段指定触发workflow的条件,通常是某些事件。
on: push |
上面代码指定,push事件触发 workflow。
on字段也可以是事件的数组。
on: [push, pull_request] |
- 上面代码指定,
push事件或pull_request事件都可以触发workflow。 - 完整的事件列表,请查看官方文档。除了代码库事件,GitHub Actions 也支持外部事件触发,或者定时运行
3. on.<push|pull_request>.<tags|branches>
指定触发事件时,可以限定分支或标签。
on: |
上面代码指定,只有
master分支发生push事件时,才会触发workflow
4. jobs.<job_id>.name
workflow文件的主体是jobs字段,表示要执行的一项或多项任务。jobs字段里面,需要写出每一项任务的job_id,具体名称自定义。job_id里面的name字段是任务的说明。
jobs: |
上面代码的jobs字段包含两项任务,job_id分别是my_first_job和my_second_job。
5. jobs.<job_id>.needs
needs字段指定当前任务的依赖关系,即运行顺序。
jobs: |
上面代码中,
job1必须先于job2完成,而job3等待job1和job2的完成才能运行。因此,这个 workflow 的运行顺序依次为:job1、job2、job3
6. jobs.<job_id>.runs-on
runs-on字段指定运行所需要的虚拟机环境。它是必填字段。目前可用的虚拟机如下。
ubuntu-latest,ubuntu-18.04或ubuntu-16.04 |
7. jobs.
steps字段指定每个Job的运行步骤,可以包含一个或多个步骤。每个步骤都可以指定以下三个字段。
jobs.<job_id>.steps.name:步骤名称。jobs.<job_id>.steps.run:该步骤运行的命令或者action。jobs.<job_id>.steps.env:该步骤所需的环境变量。
下面是一个完整的 workflow 文件的范例。
name: Greeting from Mona |
上面代码中,steps字段只包括一个步骤。该步骤先注入四个环境变量,然后执行一条 Bash 命令
二、部署实践
2.1 发布到阿里云oss
name: deploy to aliyun oss |
2.2 发布到github pages
从当前仓库发布到其他仓库的github pages
on: |
2.3 发布到阿里云服务器
rsync deployments需要使用远程主机的rsync。远程主机安装rsync [centos]
# rpm -qa|grep rsync #检查是否安装过rsync,whereis rsync也可以 |
本地生成密钥对
生成新的
Key:(引号内的内容替换为你自己的邮箱)
- 直接回车,不要修改默认路劲
- 设置一个密码短语,在每次远程操作之前会要求输入密码短语!闲麻烦可以直接回车,不设置
ssh-keygen -t rsa -C "your_email@youremail.com" |
将公钥放入远程部署机 authorized_keys 文件中
# 打开本机 .ssh 文件夹,用文本编辑器打开 id_rsa.pub 文件,复制内容到剪贴板。进入远程主机 |
远程主机将用户的公钥,保存在登录后的用户主目录的
$HOME/.ssh/authorized_keys文件中。公钥就是一段字符串,只要把它追加在authorized_keys文件的末尾就行了
将公钥
id_rsa.pub内容追加到authorized_keys末尾
centos 7 重启远程主机的ssh服务
systemctl restart sshd |
- 项目目录下新建
.github/workflows/ci.yml ci.yml只要求后缀为yml,名称无限制- 在 github 项目的设置页面添加自定义密钥供
actions配置文件引用 - 新建键值例如
MY_V2_SERVER_PRIVATE_KEY(在仓库settings/ssh中新建存放私钥) - 将本机私钥文件
id_isa重的内容全部复制到键值中
在
actions中引用格式为${{ secrets.MY_V2_SERVER_PRIVATE_KEY }}
on: |
2.4 发布到腾讯云静态网站托管
TENGXUN_OSS_SECRET_ID、TENGXUN_OSS_SECRET_KEY需要在仓库下新建,在腾讯云后台创建私钥对TENGXUN_OSS_ENV_ID环境id,参考这里获取
on: |