如何使用 github actions 快速构建流程
官网地址 ： https://docs.github.com/cn/actions
Github Actions是干什么用的？
具体的解释可以参照官网的说明，我这里举两个例子。
场景1： 一般的项目都有迭代不同的版本，但总会有一个master或dev/pro的版本做为最新版，一般的情况下，我们会在github上开不同的分支来管理，然后用版本号来区分，如下面这种：
但我们每完成一个固定的版本都需要手动更新到master或dev分支上，甚至我想再开一个仓库去存放最新版本，那我们也每次都得手动push更新。
不过这时后我们就可以用github actions，选择我们要触发的时机（pull还是push？以及在哪个分支操作），然后代码上传就可以自动同步。
场景2：github page是github提供给我们通过静态页构建博客的功能，但我们每次都需要本地打包生成静态页然后上传，不过有了actions就可以把打包以及上传的动作交给github，我们只需要新增和更新文章然后同步到github即可，甚至都可以直接在github仓库中直接修改文章都可以。
总结：上面两个例子中，知道通过actions可以上传，可以编译打包。不过，我们也可以用actions做自动化测试，只要有相应的脚本就可以实现。
Github Actions实质是什么？
简单地说，Actions就相当于Github给你提供了一个linux，你可以在里面上执行脚本。
其实Github只是给你创建了一个镜像，供你去执行脚本和命令，等你执行完了镜像会被删除。
Github Actions 脚本怎么写？
首先先看一下做为actions脚本的yml文件
1 # This is a basic workflow to help you get started with Actions 2 3 name: CI 4 5 # Controls when the action will run. Triggers the workflow on push or pull request 6 # events but only for the dev branch 7 on: 8 push: 9 branches: [ dev ] 10 pull_request: 11 branches: [ dev ] 12 13 # A workflow run is made up of one or more jobs that can run sequentially or in parallel 14 jobs: 15 # This workflow contains a single job called "build" 16 build: 17 # The type of runner that the job will run on 18 runs-on: ubuntu-latest 19 20 # Steps represent a sequence of tasks that will be executed as part of the job 21 steps: 22 # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it 23 - uses: actions/checkout@v2 24 25 # Runs a single command using the runners shell 26 - name: Run a one-line script 27 run: echo Hello, world! 28 29 # Runs a set of commands using the runners shell 30 - name: Run a multi-line script 31 run: | 32 echo Add other actions to build, 33 echo test, and deploy your project.
- name:CI 是指定流程的名称是“CI”，当actions开始执行的时候，我们点actions选项卡切换到actions页面就能看到
上图中红框的就是这个 name
- on: 指定触发时机，是push还是pull的时候触发脚本
7 on: 8 push: 9 branches: [ dev ]
这段例子的含义就是当本地的代码push到名为dev的分支中触发，如果我们不管分支只要push就触发可以这么写：
7 on:[push]
同理 pull和push类似。
- jobs里面的是脚本列表，脚本与脚本直间通过名字来区分，上面的例子中只有一个脚本，就是build，也就是说build就是脚本名，而build里面的就是脚本。
- runs-on：指定宿主环境，我们的脚本要在什么环境下执行，通常是linux，而且例子中默认给的也是这个ubuntu
runs-on: ubuntu-latest # github中也给了window和ios系统做为宿主环境
- steps：执行的步骤，里面通过 - 来区分它的步骤，name是步骤名，可以没有，下面的run用来运行命令和脚本。
一个name下可以写多个run：
30 - name: Run a multi-line script 31 run: echo Add other actions to build, 32 run: echo test, and deploy your project.
也可以写一个run: |，下一行开始写多个命令：
30 - name: Run a multi-line script 31 run: | 32 echo Add other actions to build, 33 echo test, and deploy your project.
steps中的脚本，常用的还有uses，with，env等关键字。
- steps中的uses关键字和with关键字
uses用来调用第三方依赖，with则是这个依赖方法需要的入参。
这部分很常用，因为我们在用actions的时候大多都会找一些比较成熟的工具（轮子）直接使用，很少会自己写轮子。
在下面的案例中，我会详细解释这块。
而上面模板例子里的
- uses: actions/checkout@v2
这行代码我们几乎都会用上，它可以获取到我要操作的分支的代码，就是把它checkout
Github Actions实现Github Page的自动编译打包上传
如果上面的解释你有些迷茫的话，做完下面这个，你也会操作Github Actions了。
*** 说一下yml文件，yml并不是纯脚本，这有点类似于json文件，是一种保存键值对数据的文件类型。
- 在git工程下先创建一个 .github 文件夹，如下图：
.github文件夹和你的 .git文件夹是在同一个路径下，不过一般.git文件夹默认是被隐藏的。
- 然后.github文件夹下在创建一个workflows文件夹
注意：是 workflows 而不是 workflow ， 也不是 .workflows，起初我在构建的时候就因为名字多一个点和少个s 始终无法看到到actions的页面。
- 再在workflows文件夹下创建一个yml文件，名字随便起，github只要能找到workflows文件夹，并且下面有yml文件就会执行它的脚本，如果有多个，会顺次执行。
在这我附上我本地的目录解构，方便参考：
- 以下是yml文件的写法，我每行都附上注释，方便理解
name: "github actions build and deploy gh-pages" #流程名称 on: [push] #当对当前仓库push代码的时候触发 jobs: build-and-deploy: #脚本名称 runs-on: ubuntu-latest #运行在乌班图linux上 steps: - name: Checkout #步骤1：checkout uses: actions/checkout@v2.3.1 #checkout需要引用的依赖 with: persist-credentials: false #checkout依赖参数：不保存证书 - name: install and build #步骤2：安装依赖和打包 run: | #运行下面两行命令 npm install #安装依赖，当前分支的根目录做为默认目录 npm run build #打包代码 - name: Install SSH Client #步骤3：关联ssh私钥 uses: webfactory/ssh-agent@v0.2.0 #这里调用这个第三方的库，可以直接关联ssh私钥 with: #下面是参数
#这里需要通过github的环境参数中获取私钥，并传给这个库，（这是最安全的，git当然不能让用户直接输入私钥内容） ssh-private-key: ${{ secrets.DEPLOY_KEY }} - name: Deploy #步骤4：把编译好的静态目录上传到gh-pages分支上 uses: JamesIves/github-pages-deploy-action@3.5.9 #这里调用第三方依赖，用于上传代码到指定分支上 with: SSH: true #是否通过ssh方式 BRANCH: gh-pages #github pages 默认的分支 FOLDER: dist #上传文件的目录，我这个目录在根目录下，如果是子目录可以这么写 docs/.vuepress/dist
- 上面的脚本中涉及到一个环境变量
${{ secrets.DEPLOY_KEY }}
在github上一切与用户隐私相关的，都只有登录账号的本人才能看到，比如说ssh公钥私钥，
但actions想要操作github就必须要获取这些认证，所以github给actions暴露了一些环境变量，而actions脚本可以通过${{xxxx}}的方式来获取环境变量的内容。
这里我举个例子：
在上面的这个仓库中，先选择settings选项卡，切换到仓库的设置页面，
然后左侧菜单的选择secrets进入隐私页面，右侧点New secret按钮来创建一个私钥变量，
在上图中我已经把私钥创建完了，并且名称是DEPLOY_KEY，而DEPLOY_KEY就是获取私钥的环境变量名称，
也就是脚本中的 ${{ secrets.DEPLOY_KEY }}
- 上传默认分支
Actions只识别默认分支的 .github/workflows/xxx.yml 脚本，如果脚本不在默认分支下，Actions则因为无法找到显示初始页面。
（这里算是一个坑）
如上图，我这里的工作流程在dev分支中
而dev并不是默认分支，默认分支gh-pages中并没有.github文件夹，这时我点击Actions
它会显示这个页面，这是初始页面，因为找不到workflows所以github在引导你创建一个，
而一直处在上面这个页面的原因主要是找不到工作流程文件，
git会从默认分支下找.github/workflows/*.yml文件，并且*.yml是个合法的yml脚本，你不能用json语法冒充，
所以，如果不满足上面这个条件，就会一直显示上图页面。
反观如果找到工作流程呢
就会进入这个画面，而results是每次执行的记录。
当上面的页面出现，但results并没有新增记录，原因就是on事件没有触发，on包括push和pull，那就有可能你的语法写错了。
on: [push] #这里一定要有[]中括号，否则就不会触发。
on: push: barnchs: [dev] #这里也要有[]中括号，否则不会触发
还有一点注意了，yml文件不支持 // 这种注释，习惯这么写的小伙伴如果在on或者之前添加了 //这种注释，因为语法不允许，所以也不会触发脚本。
- 通过push代码触发流程执行
如果触发了工作流程，脚本就会被执行，如上图就会多出一条记录。其中update是你在commit后面的注释。点击update进入下图
这里能看到每个job和每个step，因为只有一个job所以左侧菜单只显示一个，右侧则是按顺序执行每个step。step可以展开看到详细的信息，如下图：
这些信息方便我们查看错误。
最后附上一个执行成功的图片，以供参考：
