<!-- more -->

一、GitHubAction简介

什么是Github Action ?

GitHubActions是一个继续集成和继续交付的平台，它能够帮忙你通过自动化的构建（包含编译、公布、自动化测试）来验证你的代码，从而尽快地发现集成谬误。github于2019年11月后对该性能全面凋谢，当初所有的github用户能够间接应用该性能。GitHub 提供 Linux、Windows 和 macOS 虚拟机来运行您的工作流程，或者您能够在本人的数据中心或云基础架构中托管本人的自托管运行器。在应用Github Action之前首先须要理解以下前置常识:

  • 继续集成/继续交付的概念。
  • Git相干常识。
  • Linux或Windows或macOS脚本相干常识。
  • Yaml根底语法。

什么是Yaml ?

编写GithubAction的流程时，须要创立一个workflow工作流，workflow必须存储在你的我的项目库根门路下的.github/workflows目录中，每一个 workflow对应一个具体的.yml 文件（或者 .yaml）。

yml是YAML（YAML Ain’t Markup Language）语言的文件，以数据为核心，比properties、xml等更适宜做配置文件，次要有以下几个特点:

  • 大小写敏感。
  • 应用缩进示意层级关系。
  • 缩进只能应用空格，不能用 TAB 字符。
  • 缩进的空格数量不重要，只有层级雷同的元素左对齐即可。
  • ‘#’ 示意正文。

Github Action基本概念

  • workflow: 一个 workflow 就是一个残缺的工作流过程，每个workflow 蕴含一组 jobs工作。
  • job : jobs工作蕴含一个或多个job ，每个 job蕴含一系列的 steps 步骤。
  • step : 每个 step 步骤能够执行指令或者应用一个 action 动作。
  • action : 每个 action 动作就是一个通用的根本单元。

Github Action 的应用限度

在应用收费版本的Github Action是有如下限度的:

  • 作业执行工夫 - 工作流中的每个作业最多能够运行 6 小时的执行工夫。如果作业达到此限度，该作业将终止且无奈实现。
  • 工作流运行工夫 - 每个工作流运行限度为 35 天。如果工作流运行达到此限度，则工作流运行将被勾销。此时间段包含执行持续时间以及期待和批准所破费的工夫。
  • API 申请 - 您能够在一小时内跨存储库中的所有操作执行多达 1000 个 API 申请。如果超出此限度，其余 API 调用将失败，这可能会导致作业失败。
  • 并发作业 - 能够在帐户中运行的并发作业数取决于 GitHub 打算，如下表所示。如果超出，则任何其余作业都将排队。

  | GitHub 打算 | 并发作业总数 | 最大并发 macOS 作业数 |

  | :---------: | :----------: | :-------------------: |

  |    自在     |      20      |           5           |

  |   专业版    |      40      |           5           |

  |    团队     |      60      |           5           |

  |    企业     |     180      |          50           |

  • 作业矩阵 - 作业矩阵每次工作流运行最多能够生成 256 个作业。此限度实用于 GitHub 托管和自托管的运行程序。
  • 工作流运行队列 - 每个存储库的排队工夫距离不超过 500 个工作流运行，距离为 10 秒。如果工作流运行达到此限度，则工作流运行将终止且无奈实现。

具体以最新版官网文档为主:usage-limits-billing-and-administration

二.GitHubAction的应用

workflow

在我的项目库根门路下的.github/workflows目录中创立一个.yml 文件（或者 .yaml）:

name: hello-github-actions# 触发 workflow 的事件on: push: # 分支随便 branches:- master# 一个workflow由执行的一项或多项jobjobs: # 一个job工作，工作名为build build: #运行在最新版ubuntu零碎中 runs-on: ubuntu-latest #步骤合集 steps: #新建一个名为checkout_actions的步骤- name: checkout_actions #应用checkout@v2这个action获取源码 uses: actions/checkout@v2 #应用建一个名为setup-node的步骤- name: setup-node #应用setup-node@v1这个action uses: actions/setup-node@v1 #指定某个action 可能须要输出的参数 with: node-version: '14'- name: npm install and build #执行执行某个shell命令或脚本 run: |          npm install          npm run build- name: commit push #执行执行某个shell命令或脚本 run: |          git config --global user.email xxx@163.com          git config --global user.name xxxx          git add .          git commit -m "update" -a          git push         # 环境变量 env: email: xxx@163.com

name

Workflow的名字，轻易能够设置，就是工作流的名字。如果省略该字段，默认为以后 workflow 的文件名。

name: hello-github-actions

on

触发的事件，能够是一个事件数组。

在代码仓库Push时触发:

#push时触发on: push

能够用数组指定多个条件触发:

#push和merge时触发on: [push, merge]

还能够对条件进行限度触发:

#当master分支push时触发，能够限定分支或标签。on: push: branches:- master

残缺的事件列表，请查看官网文档。除了代码库事件，GitHub Actions 也反对内部事件触发，或者定时运行。

jobs

1.job

jobs示意要执行的一项或多项工作。jobs能够蕴含一个或多个job，一个job就是一个工作，这个工作能够蕴含多个步骤(steps):

jobs: job1: ... job2: ...

须要留神的是每一个Job都是并发执行的并不是依照申明的先后顺序执行的， 如果多个job 之间存在依赖关系，那么你可能须要应用 needs :

jobs: job1: job2: needs: job1 job3: needs: [job1, job2]

这里的needs申明了job2 必须期待 job1 胜利实现，job3必须期待 job1 和 job2顺次胜利实现。因而，这个 workflow 的运行程序顺次为：job1、job2、job3。needs字段指定当前任务的依赖关系，即运行程序。

2.job->runs-on

runs-on字段指定运行所须要的虚拟机环境。它是必填字段，目前可用的虚拟机如下:

  • ubuntu-latest，ubuntu-18.04或ubuntu-16.04。
  • windows-latest，windows-2019或windows-2016。
  • macOS-latest或macOS-10.14。

指定job的运行环境:

jobs: job1: runs-on: ubuntu-18.04 job2: runs-on: macos-10.15 job3: runs-on: windows-2019

github 会提供一个配置很不错的服务器做为 runner，Windows 和 Linux 虚拟机的硬件规格：

  • 2 核处理器。
  • 7 GB 内存。
  • 14 GB 固态硬盘空间。

macOS 虚拟机的硬件规格：

  • 3 核处理器。
  • 14 GB 内存。
  • 14 GB 固态硬盘空间。
如果你有网络时延的需要，（比方推送及拉取镜像时产生的网络时延），你也能够自建runner 。

3.job->env

应用env能够给该工作或者是步骤配置环境变量:

 env:   name: "zhangsan" run: |   echo $name

环境变量能够配置在以下中央:

  • jobs->job->env
  • jobs->job->steps.env

 4.job->steps

steps字段指定每个 Job 的运行步骤，每个job由多个step形成，它会从上至下顺次执行。steps能够蕴含一个或多个步骤，每个 step 步骤能够有:

  • name：步骤名称，步骤的名称。
  • env：该步骤所需的环境变量。
  • id : 每个步骤的惟一标识符
  • uses : 应用哪个action，这个示意应用他人事后设置好的Actions，比方因为我代码中要用到python，所以就用了actions/setup-
  • python@v1来设置python环境，不必我本人设置了。
  • with: 指定某个action 可能须要输出的参数。
  • run: 执行哪些指令，具体运行什么命令行代码。
  • continue-on-error : 设置为 true 容许此步骤失败job 依然通过。
  • timeout-minutes : step 的超时工夫。

  例如:

  `yaml

...

name: Sync To Gitee

on: [ push ]

jobs:

sync:

runs-on: ubuntu-latest

steps:

#创立一个打印环境变量的步骤

  • name: PrintName

    env:

    name: "zhangsan"

    run: |

    echo $name

    #创立一个装置Python环境的步骤    

  • name: SetUpPython

    uses: actions/setup-python@v1

    with:

    python-version: 3.7

    #创立一个装置Python包的步骤

  • name: Install dependencies

    run: |

    python -m pip install --upgrade pip

    pip install requests

    pip install bs4

    pip install lxml

  `

应用uses指的是这一步骤须要先调用哪个 Action。 Action 是组成工作流最外围最根底的元素。 每个 Action 能够看作封装的独立脚本，有本人的操作逻辑，咱们只须要 uses 并通过 with 传入参数即可。 比方 actions/checkout@v2 就是官网社区奉献的用来拉取仓库分支的 Action， 你不须要思考装置 git 命令工具，只须要把分支参数传入即可。

5.Action

Github Actions 是GitHub的继续集成服务。继续集成由很多操作组成，比方登录近程服务器，公布内容到第三方服务等等，这些雷同的操作齐全能够提取进去制作成脚本供所有人应用。GitHub容许开发者把每个操作写成独立的脚本文件，寄存到代码仓库，使得其余开发者能够援用该脚本，这个脚本就是一个Action。如果你须要某种性能的Action能够从GitHub社区共享的action官网市场查找，也能够本人编程Action开源进去供大家应用。既然 actions 是代码仓库，当然就有版本的概念，用户能够援用某个具体版本的 action。 上面都是非法的 action 援用:

actions/setup-node@74bc508  # 指向一个 commitactions/setup-node@v1.0 # 指向一个标签actions/setup-node@master # 指向一个分支

GitHub Actions 中应用密文

在继续集成的过程中，咱们可能会应用到本人的敏感数据，这些数据不应该被开源并泄露。那么如何能力平安的应用这些敏感数据呢?GithubActions提供了Secrets变量来实现这一成果。咱们能够在 github repo 上顺次点击 Settings -> Secrets-> Actions->New repository secret创立一个敏感数据例如:OSS_KEY_ID，OSS_KEY_SECRET， 而后咱们就能够在GithubAction脚本中应用这一变量了:

-  name:  setup  aliyun  oss uses:  manyuanrong/setup-ossutil@master with: endpoint:  oss-cn-beijing.aliyuncs.com access-key-id:  ${{  secrets.OSS_KEY_ID  }} access-key-secret:  ${{  secrets.OSS_KEY_SECRET  }}

这里的secret就是一种context，形容 CI/CD 一个workflow 中的上下文信息，应用${{ expression }}语法示意。更多context信息能够参考官网文档

GitHubAction执行后果

对于GitHubAction的执行流程咱们能够通过repo 上顺次点击Actions就能够看到Action的状态和执行后果等信息:

三.示例

应用GitHubAction实现Push代码发送邮件告诉性能。 次要通过 GitHub Action 监听代码 push 事件，并发送邮件（前提是邮箱须要开明 SMTP 服务）。

在我的项目中 ./github/workflows/ 门路下增加 .yml 或者 .yaml文件，名字能够轻易取。在这里我取名为 github-action-email.yml:

name: github-action-emailon: [push]jobs: build: runs-on: ubuntu-latest steps: # 检出代码- name: CheckoutRepo uses: actions/checkout@v2 # 获取master分支上最新一条提交的git log  - name: GetLastLog 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}}
  • secrets.XXX ： GitHub 容许仓库所有者创立和治理须要保密性的参数。例如邮件的账号和明码都是属于敏感参数。 能够通过我的项目
  • Settings -> Secrets -> Actions配置明码，在这里咱们增加 MAIL_USERNAME、MAIL_PASSWORD、MAIL_TOUSERNAME 三个配置参数（留神：这里的明码是指 SMTP 服务的受权明码）。

  上下文：能够拜访工作流程运行、运行器环境、作业及步骤相干信息的形式${{github.repository}}：以后仓库的的所有者和仓库名称。${{steps.git_log_outputs.log}} ：获取step id 为 git_log 的输入集。

因为咱们定义 push 为触发条件，所以当咱们只有push 代码后，咱们定义的 GitHub Action 才会被执行。而后在 GitHub 上的 Action 可能实时看到以后的执行状态。

转载至 GitHubActions详解