当前位置:   article > 正文

Github Action

github action

1. Github Action 基本概念

1.1 什么是 Github Action

Automate your workflow from idea to production.
GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triaging work the way you want.

Github Action是GitHub 推出的持续集成 (Con­tin­u­ous in­te­gra­tion, CI) 服务,它提供了配置非常不错的虚拟服务器环境,基于它可以进行构建、测试、打包、部署项目。让开发者自动化实现定制化工作流逻辑的平台,集成了持续集成和交付(CI/CD)功能,可以让开发者自动化完成一系列工作流

Github Actions 的最大优势就是它是与 GitHub 高度整合的,只需一个配置文件即可自动开启服务。甚至你不需要购买服务器 —— GitHub Actions 自带云环境运行,包括私有仓库也可以享用,而且云环境性能也非常不错(2 cores, 7GB)。

背景:CI/CD 工作流程

  • CI (Continuous Integration)
    持续集成指的是,频繁地(一天多次)将代码集成到主干,持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量。它的核心措施是,代码集成到主干之前,必须通过自动化测试。

  • Continuous Delivery
    持续交付指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。 持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。

  • Continuous Deployment
    持续部署(continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。

基本流程:

  1. 提交commit,是开发者向代码仓库提交代码;
  2. CI 测试:代码仓库对commit操作配置了钩子(hook),只要提交代码或者合并进主干,就会跑自动化测试。 测试有好几种。单元测试、集成测试、端到端测试
  3. 构建: 通过第一轮测试,代码就可以合并进主干,交付后就先进行构建(build),再进入第二轮测试。所谓构建,指的是将源码转换为可以运行的实际代码,比如安装依赖,配置各种资源(样式表、JS脚本、图片)等等。常用的构建工具 Jenkins、Travis、Codeship、Strider
  4. 第二轮测试, 第二轮是全面测试,单元测试和集成测试都会跑,有条件的话,也要做端对端测试。所有测试以自动化为主,少数无法自动化的测试用例,就要人工跑。
  5. 部署: 通过了第二轮测试,当前代码就是一个可以直接部署的版本(artifact)。将这个版本的所有文件打包( tar filename.tar * )存档,发到生产服务器。
  6. 回滚:一旦当前版本发生问题,就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接,指向上一个版本的目录
    在这里插入图片描述

1.2 Github Action 有什么功能

  • 跨平台多语言支持的测试环境: 如Linux、Linux Container、Windows、ARM 和 macOS 等,包括主流的开发语言,如 Node.js、Python、Java、PHP、Ruby、C/C++、.NET,以及 Android 和 iOS 设备上的开发语言

  • 自动化代码构建和部署工作流:

  • 可复用的 action 和工作流文件: 基于 YAML 文件构建的,开发者只需要在文件中添加几行代码就可以完成设置,GitHub Actions 的文件是代码,开发者可以编辑、复用,或者像 fork 代码那样 fork 这些文件。 特别是当开发者 fork 了一个代码库的时候,其中的 action 会和源代码一样被 fork。 因此开发者可以像代码提供者那样进行测试和编译工作。

  • 实时显示运行结果:动态日志可以在程序运行过程中显示结果。 GitHub 流可以将程序日志导入到 Actions 的显示框中,实时展示运行过程。

  • 自动构建集成化的包和容器库:在持续集成和部署中,发布包和容器是关键的一环,特别是发布开源库或部署大型网络服务。 GitHub Actions 简化了发布流程。 接入 Actions 平台的开发者同时也能够接入 GitHub Package Registry,可以自动化从构建包到部署中间的所有工作流程。

1.3 什么是 action

Github Actions是由Github创建的 CI/CD服务。 它的目的是使所有软件开发工作流程的自动化变得容易。 直接从GitHub构建,测试和部署代码。CI(持续集成)由很多操作组成,比如代码合并、运行测试、登录远程服务器,发布到第三方服务等等。GitHub 把这些操作就称为 actions

actions可以共享。GitHub 允许开发者把每个操作写成独立的脚本文件,存放到代码仓库,使得其他开发者可以引用。


2. 如何使用 Github Action

2.1 基本概念

  • workflow (工作流程):持续集成一次运行的过程
  • job (任务):一个 workflow 由一个或多个 job 构成,表示一次持续集成的运行,可以完成多个任务
  • step(步骤):每个 job 由多个 step 构成,一步步完成
  • action (动作):每个 step 可以依次执行一个或多个命令(action)

2.2 资源限制

GitHub Ac­tions 为每个任务 (job) 都提供了一个虚拟机来执行,每台虚拟机都有相同的硬件资源:
2-core CPU, 7 GB RAM 内存, 14 GB SSD 硬盘空间,硬盘总容量为90G左右,可用空间为30G左右。

每个仓库只能同时支持20个 workflow 并行。
每小时可以调用1000次 GitHub API 。
每个 job 最多可以执行6个小时。
免费版的用户最大支持20个 job 并发执行,macOS 最大只支持5个。
私有仓库每月累计使用时间为2000分钟,超过后$ 0.008/分钟,公共仓库则无限制。
操作系统方面可选择 Win­dows server、Linux、ma­cOS,并预装了大量软件包和工具。

2.3 可借鉴的 Github Actions

GitHub 做了一个GitHub Marketplace ,可以搜索到他人提交的 actions。另外,还有一个Awesome Actions的仓库,也可以找到不少 action

3. 语法规则

  • Ac­tions 的配置文件叫做 work­flow 文件,存放在代码仓库的.github/workflows 目录中
  • work­flow 文件采用 YAML 格式,文件名可以任意取,但是后缀名统一为.yml,如build.yml
  • Github 会按照work­flow 文件中所指定的触发条件在符合条件时自动运行该文件中的工作流程。

3.1 work­flow 文件的语法规则:

name 字段

work­flow 的名称。若忽略此字段,则默认会设置为 work­flow 文件名,一般表示workflow的功能

# 一般name 表示此 workflow的功能
name: GitHub Actions Demo     
name: Build    
  • 1
  • 2
  • 3

on 字段

表示work­flow 的触发条件,通常是某些事件,[push, pull_request 等] 触发事件详细语法

name: GitHub Actions Demo
on: [push]
on: [push, pull_request]
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration does not affect the page_build event above
      - created

on:
  push:
    paths-ignore: ## 也可以添加 ignore, 避免不必要的触发
      - '**.md'
      - 'LICENSE'
      - '.gitignore'
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22

jobs字段

表示要执行的一项或多项任务。每一项任务必须关联一个 ID名称 (job_id),当有多个任务时,可以指定任务的依赖关系,即运行顺序,否则是同时运行jobs语法

jobs:
  my_first_job:
    name: My first job
    .......
  my_second_job:
    name: My second job
    ......
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
job里的字段的语法规则
runs-on 字段

指定任务运行所需要的虚拟服务器环境,是必填字段, runs_on语法

jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
    .......

  other_job:
  	
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
strategy字段
  • 可以配置strategy.matrix变量, 进行不同环境、不同语言、不同工具的多个jobs并行操作stategy 语法
  • fail-fast 默认为true, 只要任何 matrix job failed, 则停掉所有jobs
  • max-parallel 配置并行 jobs的最大数量
# strategy matrix 示例
runs-on: ${{ matrix.os }}
strategy:
  fail-fast: false
  max-parallel: 2
  matrix:
    os: [ubuntu-18.04, ubuntu-20.04]
    node: [10, 12, 14]
steps:
  - uses: actions/setup-node@v2
    with:
      node-version: ${{ matrix.node }}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
env字段

设置适用于当前 job的所有steps的环境变量

jobs:
  job1:
    env:
      DOCKER_IMAGE: ${{ matrix.ubuntu-version }}
  • 1
  • 2
  • 3
  • 4
steps 字段

指定每个任务的运行步骤,可以包含一个或多个步骤(action)。步骤开头使用 - 符号。每个步骤可以指定以下字段: steps语法

  • name:步骤名称, name可省略
  • uses:该步骤引用的action或 Docker 镜像。
  • run:该步骤运行的 bash 命令。
  • env:该步骤所需的环境变量。 其中 uses 和 run 是必填字段,每个步骤只能有其一。同样名称也是可以忽略的。
name: GitHub Actions Demo
on: [push]
jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: echo "
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/你好赵伟/article/detail/186009
推荐阅读
相关标签