针不戳！GitHub Actions 入坑指南_jobs.build.runs-on

前言

相信关注技术前沿的同学，多少也了解过 GitHub Actions

小年我碰巧最近遇上使用的需求，体验了一番之后，感觉两个字：真香！

什么是 GitHub Actions ？

GitHub Actions 是 GitHub 推出的持续集成（Continuous Integration，简称 CI）服务，它提供了整套虚拟服务器环境，基于它可以进行构建、测试、打包、部署项目等等操作。

持续集成（CI \ CD）主要有三个： 持续集成、持续交付、持续部署。

我们一般的软件开发流程是：

1. 开发人员本地代码 commit
2. 通过 git hook 触发自动化测试
3. 测试通过后，合并发布分支
4. 通过 git hook 触发自动部署服务

这里简单的描述了软件开发周期，当然实际上会更加复杂。

我们可以看到，CI \ CD 是由很多操作组成的，比如执行自动化测试、分支合并、服务部署等，而 GitHub 把这一系列的操作都称为 Actions。

当然 GitHub 创新点还不仅于此，不同的项目可能都会使用到相类似的 Action，GitHub 允许开发者把 action 写成独立的脚本文件，存放到代码仓库，使得其他开发者可以引用。

GitHub 提供一个官方市场：GitHub Action Market ，在这里可以搜索到你想要的任何 actions，直接引用别人造好的轮子。

基本概念

GitHub Actions 主要有以下几个概念

• Workflows

  工作流，可以添加到存储库中的自动化过程。工作流由一个或多个作业组成，可以由事件调度或触发。

• Event

  事件，触发工作流的特定动作。例如，向存储库提交 pr 或 pull 请求。

• Jobs

  作业，在同一跑步器上执行的一组步骤。默认情况下，具有多个作业的工作流将并行运行这些作业。

• Steps

  步骤，可以在作业中运行命令的单个任务。步骤可以是操作，也可以是 shell 命令。作业中的每个步骤都在同一个运行程序上执行，从而允许该作业中的操作彼此共享数据。

• Actions

  操作是独立的命令，它们被组合成创建作业的步骤。操作是工作流中最小的可移植构建块。你可以创建自己的动作，或者使用 GitHub 社区创建的动作。

• Runners

  运行器，安装了 GitHub Actions 运行器应用程序的服务器。。Github 托管的运行器基于 Ubuntu Linux、Microsoft Windows 和 macOS，工作流中的每个作业都在一个新的虚拟环境中运行。

快速入门

闲话少说，咱们先通过简单的实例来体验一下 GitHub Action 的玩法。

实例一：发送邮件

例子比较简单，主要通过 GitHub Action 监听代码 push 事件，并发送邮件。（前提是邮箱需要开通 SMTP 服务）

第一步，在项目中 ./github/workflows/ 路径下添加 .yml 或者 .yaml文件，名字可以随便取。在这里我取名为 github-action-demo.yml

下面是 github-action-demo.yml 的内容：

name: GitHub Action Demo
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    # copy git 仓库到虚拟机上
    - name: 'Checkout codes'
      uses: actions/checkout@v1
    # 获取最新一条提交的git log  
    - name: Get Git Log
      id: git_log
      uses: Edisonboy/latest-git-log-action@main
      with:
        tag: origin/master
    # 发送邮件    
    - name: Send email
      uses: dawidd6/action-send-mail@v3
      with:
        server_address: smtp.qq.com
        server_port: 465
        username: ${{secrets.MAIL_USERNAME}}
        password: ${{secrets.MAIL_PASSWORD}}
        subject: Github Actions job result
        to: ${{secrets.MAIL_TOUSERNAME}}
        from: ${{secrets.MAIL_USERNAME}}
        body: ${{github.repository}} push log : ${{steps.git_log.outputs.log}}
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

这个 .yml 文件就是对 GitHub Action 的定义，这里大概讲解一下主要的步骤，有关具体的语法，下文面再详解

1. on: [push] 项目 push 的时候触发
2. jobs.build.runs-on 运行在 ubuntu 的虚拟机上
3. jobs.build.steps 定义了不同的步骤，如上注释

第二步，配置参数

聪明的同学可能还会问，那文件上的 ${{XXX}} 变量又是从何而来，哪里定义的呢？

上面的实例只要使用了两种类型的参数变量：

• secrets.XXX ： GitHub 允许仓库所有者创建和管理需要保密性的参数。例如邮件的账号和密码都是属于敏感参数。

  可以通过项目 Settings -> Secrets -> Actions 配置密码，在这里我们添加 MAIL_USERNAME、MAIL_PASSWORD、MAIL_TOUSERNAME 三个配置参数（注意：这里的密码是指 SMTP 服务的授权密码）

  

• 上下文：可以访问工作流程运行、运行器环境、作业及步骤相关信息的方式

  • ${{github.repository}} ：当前仓库的的所有者和仓库名称。例如 Edisonboy/ActionDemo
  • ${{steps.git_log_outputs.log}} ：获取step id 为 git_log 的输出集

第三步，因为我们定义 push 为触发条件，所以当我们只有push 代码后，我们定义的 GitHub Action 才会被执行。然后在 GitHub 上的 Action 能够实时看到当前的执行状态。

等运行完后，咱们就能收到 git push 的日志邮件了！！！

实例地址：Edisonboy/ActionDemo

实例二：Github 同步 Gitee

参考：利用 GitHub Actions 实现 github 代码同步 gitee 仓库

Workflow 语法

结合上面的例子，咱们简单学习一下 workflow 的语法。

workflow 文件必须存储在仓库的 .github/workflows 的目录中，扩展名为 .yml 或 .yaml

name

workflow 的名称， GitHub 在仓库的操作页面上显示 workflow 的名称。

on

触发 workflow 的 GitHub 事件的名称。

# 单个事件
on: push

# 多个事件列表
on: [push, pull_request]

# 指定main分支的push
on:
  push:
    branches:
      - main
1
2
3
4
5
6
7
8
9
10
11

还可以使用定时调度：

on:
  schedule:
    - cron: '*/30 5,17 * * *'
1
2
3

Jobs

作业，workflow 主要执行的核心任务。

jobs.<job_id>

每项作业必须关联一个 ID。例如上面实例的 ID 为 build

jobs.<job_id>.name

作业显示在 GitHub 上的名称。

jobs.<job_id>.needs

识别在此作业运行之前必须成功完成的任何作业。

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]
1
2
3
4
5
6

在此示例中，job1 必须在 job2 开始之前成功完成，而 job3 要等待 job1 和 job2 完成。

jobs.<job_id>.runs-on

要运行作业的机器类型。 机器可以是 GitHub 托管的运行器或自托管的运行器。

可用的 GitHub 托管的运行器类型包括：

jobs.<job_id>.steps

步骤，每个 Job 包含一个或多个步骤。步骤可以是运行命令、运行设置任务，或者运行仓库中的操作和 Dcoker 镜像发布等。

例如上面实例定义了 3 个步骤 ：

1. copy git 仓库到虚拟机上
2. 获取最新一条提交的git log
3. 发送邮件

每个步骤都可以定义以下几个字段：

jobs..steps[*].id : 步骤的唯一标识符
jobs..steps[*].name : 步骤显示在 GitHub 上的名称
jobs..steps[*].if : 自定义表达式，判断是否满足条件
jobs..steps[*].uses : 选择公共仓库中、或发布 Docker 容器映像作为一部分运行的操作。例如上面的实例都是使用了公共仓库提供的操作
jobs..steps[*].run : 运行 shell 命令程序。
1
2
3
4
5

有关 workflow 语法更多的细节使用可以参考： GitHub Actions 官方文档

小结

在执行 workflow 的过程中，GitHub 会自动为我们提供相应的虚拟服务器资源，这时候脑洞大的同学就应该想到：有没有可能连接到这个服务器，白嫖一个服务器为所欲为呢。

看了一下 GitHub Actions 官方文档上提供的虚拟服务器资源，这个配置比一台低配个人服务器还香。

Windows 和 Linux 虚拟机的硬件规格：

• 2 核 CPU
• 7 GB RAM 内存
• 14 GB SSD 硬盘空间

MacOS 虚拟机的硬件规格：

• 3 核 CPU
• 14 GB RAM 内存
• 14 GB SSD 硬盘空间

有兴趣的同学可以参考：SSH 连接到 GitHub Actions 虚拟服务器

还有更硬核的操作！ 黑客可谓把白嫖发挥得淋漓尽致，尽然想到利用 GitHub 的服务器挖矿 （详情：黑客用GitHub服务器挖矿，三天跑了3万个任务，代码惊现中文）

当然 GitHub Actions 也没有这么傻，肯定想到咱们白嫖的各种骚操作，所以对于使用增加了一定的限制

总的来说，GitHub Actions 是一个非常实用有趣的功能，没有你做不到的，只有你想不到的。

参考资料

GitHub Actions 官方文档

GitHub Actions 入门教程-阮一峰

GitHub Actions 进阶技巧