针不戳!GitHub Actions 入坑指南

针不戳!GitHub Actions 入坑指南

Scroll Down

前言

相信关注技术前沿的同学,多少也了解过 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}}

这个 .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_USERNAMEMAIL_PASSWORDMAIL_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

还可以使用定时调度:

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

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]

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

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 命令程序。

有关 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 进阶技巧

普通的改变,将改变普通

我是宅小年,一个在互联网低调前行的小青年

关注公众号「宅小年」,个人博客 📖 edisonz.cn,阅读更多分享文章