GitHub Action入门简介

1. What is GitHub Actions?

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

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

2. 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的触发方式有两种：1.手动触发 2. 通过定义触发事件自动触发 3. 通过Post 一个Rest API请求。

一个repo可以有多个Workflow

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

• Events

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

• Jobs

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

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

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

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

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

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

• Acitons

Action是Github Acitons 平台自定义的应用，可以执行复杂但频繁重复的任务。

也就是说将重复使用的Workflow抽象成一个模块，方便重复使用，减少重复性代码。

• Runners

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

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

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

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

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

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 个。 如果工作流程运行达到此限制，该工作流程运行将会终止而无法完成。