这里插入图片描述

Github Action 官方文档：https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#name

Github Action 是什么？

GItHub Actions是 Github 推出的一个持续集成和持续交付的平台，能够让你自动化你的编译、测试和部署流程。

GitHub 提供 Linux、Windows 和 macOS 虚拟机来运行您的工作流程，或者您可以在自己的数据中心或云基础架构中托管自己的自托管运行器。

持续集成是什么？

简单说就是自动化的打包程序——如果是前端程序员，这样解释比较顺畅：

每次提交代码到 Github 的仓库后，Github 都会自动创建一个虚拟机（Mac / Windows / Linux 任我们选），来执行一段或多段指令（由我们定），例如：

npm install
npm run build

Yaml 是什么？

我们集成 Github Action 的做法，就是在我们仓库的根目录下，创建一个 .github 文件夹，里面放一个 *.yaml 文件——这个 Yaml 文件就是我们配置 Github Action 所用的文件。

它是一个非常容易地脚本语言，如果我们不会的话，也没啥大事继续往下看就成了。

Github Action 的使用限制

每个 Workflow 中的 job 最多可以执行 6 个小时
每个 Workflow 最多可以执行 72 小时
每个 Workflow 中的 job 最多可以排队 24 小时
在一个存储库的所有 Action 中，一个小时最多可以执行 1000 个 API 请求
并发工作数：Linux：20，Mac：5（专业版可以最多提高到 180 / 50）

Github Actions 的组成？

整体流程：

在github repo中特定事件发生时，workflow会被触发。

一个workflow由若干个job组成，这些job可以顺序运行，也可以并行运行。

每个job运行在自己的虚拟机runner或者容器中。

每个job由若干个step组成，这些step可以是运行脚本或者执行一个action。

action是可以复用的拓展，用来简化workflow 。

          --------- job1
         |
         |
workflow ---------- job2
  			 |               ------- step1
  			 |              |
  			  --------- job3 ------- step2 
  			  							|
  			  							 ------- step3

Workflows

Workflow是可配置的自动化进程，它会运行一个或多个Jobs。

Workflow通过yaml配置文件来定义

Worklofw的触发方式有两种：

手动触发
通过定义触发事件自动触发
通过Post 一个Rest API请求。

一个repo可以有多个Workflow

可以在一个Workflow中引用另一个Workflow

Events

Events是一种能够触发Workflow运行的特定的活动，包括创建pull请求，开启一个issue或者进行一次commit

// 单个事件
on: push

// 多个事件
on: [push,pull_request]

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-workflow-events

Jobs

Job是Step的集合，一个Job包含若干个Steps。

每个Steps可以是将被执行的Shell命令或脚本。

不同的Jobs可以在不同的虚拟环境runner上执行若干个命令或脚本。

但一个Job只能在相同的runner上执行workflow的一系列步骤，正因如此，一个Job中的若干个Steps可以共享数据。

Job之间可以配置依赖，默认情况下Jobs彼此之间没有依赖且并行执行。

在配置了依赖的情况下，一个Job需要等待它所依赖的Job运行完成后才能运行。

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

每个 job 必须具有一个 id 与之关联。

上面的 my_first_job 和 my_second_job 就是 job_id。

Acitons

相比较持续集成这个大概念，GitHub推出的 Actions 就显得非常轻量和巧妙了。Actions就相当于持续集成中的某个特定功能的脚本，通过多个actions的自由组合，便可实现自己特定功能的持续集成服务。

同时，Github为了方便大家使用 Actions，还专门做了一个 Actions市场, 真的是非常方便！

Runners

Runner是在workflow被触发时用来运行workflow的服务器。

每个Runner每次只能运行一个Job

Github提供了Ubuntu Linux，Microsoft Windows, macO runner来运行workflows。

每个workflow在全新的初始化的虚拟机上执行。

如果有需要，还可以使用自己的服务器主机来运行workflow。自定义主机

jobs.<job_id>.runs-on

指定运行 job 的运行环境，Github 上可用的运行器为：

windows-2019
ubuntu-20.04
ubuntu-18.04
ubuntu-16.04
macos-10.15

jobs:
  job1:
    runs-on: macos-10.15
  job2:

Example：helloWorkflow.yaml

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

name : Workflow的名字
on: 触发的Events，可以是一个Events数组
jobs ：指定这个Workflow包含的Jobs
Check-bats-version：job的名字
runs-on：指定运行的Runner
steps：Job中包含的Steps
uses：使用某个action
run：执行某个shell命令或脚本
with：指定需要传入的参数

使用限制

如果使用Github提供的Runners，使用限制如下：

工作流程运行时间 ：每个工作流程的运行时限为 72 小时。如果工作流程运行时间达到此限制，其运行将被取消。
API 请求 ：在一个仓库的所有操作中，一个小时内最多可执行 1000 个 API 请求。如果超出，额外的 API 调用将失败，这可能导致作业失败。
详细限制请查看：Usage limits, billing, and administration

如果使用自己的云服务器，使用限制如下：

工作流程运行时间 - 每个工作流程的运行时限为 72 小时。如果工作流程运行时间达到此限制，其运行将被取消。
工作队列时间 ：每个自己服务器上的Job最大可以排队24的消失。如果在此限制内还没有开始执行，那么这个Job就会终止，宣告执行失败。
API 请求 - 在一个仓库的所有操作中，一个小时内最多可执行 1000 个 API 请求。如果超出，额外的 API 调用将失败，这可能导致作业失败。
Job matrix - 作业矩阵在每次工作流程运行时最多可生成 256 个作业。此限制也适用于自托管运行器。
工作流程运行队列 - 每个仓库在 10 秒的间隔内可排队的工作流程运行不超过 500 个。如果工作流程运行达到此限制，该工作流程运行将会终止而无法完成。

参考

白嫖Github Action做定时任务
 GitHub Actions 手动触发方式进化史

https://github.com/guodongxiaren/py

利用 github action 爬取必应每日超清壁纸
 阮一峰 - GitHub Actions 入门教程

Github Action 指南