基于 Github Action 的 CI/CD 流程

最新推荐文章于 2023-08-01 00:51:07 发布

AlwaysDayOne

最新推荐文章于 2023-08-01 00:51:07 发布

阅读量1.2k

点赞数 1

文章标签： github ci/cd

本文链接：https://blog.csdn.net/weixin_44639164/article/details/122119026

版权

基于 Github Action 的 CI/CD 流程

https://github.com/features/actions
GitHub Marketplace: apps to improve your workflow

在大型的开源项目或者软件开发过程中，很多开发者都会去提交PR或者进行代码的 push操作。如果对于每次代码合并都需要项目的核心维护者进行 code review，这项工作是极其困难而且耗时的。因此许多团队都会制定一套代码规范, 然后编写测试用例严格的检查每次代码修改，这样能够非常有效的减少后期代码维护的成本。

在github中也引入了一台CI/CD 工作流——Github Actions，这是 GitHub 推出的持续集成 (Continuous integration，简称 CI) 服务，它提供了配置非常不错的虚拟服务器环境，基于它可以进行构建、测试、打包、部署项目。

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

本篇文章将介绍 GitHub Actions 的基本使用方法与给出一个快速开始的实例。

CI (Continuous integration，持续集成)

互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成。持续集成指的是，频繁地将代码集成到主干。它的好处主要有两个：

快速发现错误。每完成一点更新，就集成到主干，可以快速发现集成环境的错误。
防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

CD

持续交付

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

持续部署

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

GitHub Actions

Github Actions是由Github创建的 CI/CD服务。直接从GitHub构建，测试和部署代码。CI（持续集成）由很多操作组成，比如代码合并、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作就称为 actions。

很多操作在不同项目里面是类似的，完全可以共享。GitHub 允许开发者把每个操作写成独立的脚本文件，存放到代码仓库，使得其他开发者可以引用。

如果你需要某个 action，不必自己写复杂的脚本，直接引用他人写好的 action 即可，整个持续集成过程，就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。

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

基础概念

GitHub Actions 有一些自己的术语。

workflow：持续集成一次运行的过程。
job：一个 workflow 由一个或多个 job 构成，含义是一次持续集成的运行，可以完成多个任务。
step：每个 job 由多个 step 构成，一步步完成。
action：每个 step 可以依次执行一个或多个命令（action）。

虚拟环境

GitHub Actions 为每个任务 (job) 都提供了一个虚拟机来执行，每次job启动时都会构建一个新的虚拟环境，每台虚拟机都有相同的硬件资源：

2-core CPU, 7 GB RAM 内存, 14 GB SSD 硬盘空间
硬盘总容量为90G左右，可用空间为30G左右，评测详见：《GitHub Actions 虚拟服务器环境简单评测》

使用限制：

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

workflow 文件

GitHub Actions 的配置文件叫做 workflow 文件，存放在代码仓库的.github/workflows 目录中。

workflow 文件采用 YAML 格式，文件名可以任意取，但是后缀名统一为.yml，比如 build.yml。一个库可以有多个 workflow 文件，GitHub 只要发现.github/workflows 目录里面有.yml 文件，就会按照文件中所指定的触发条件在符合条件时自动运行该文件中的工作流程。

在 Actions 页面可以看到很多种语言的 workflow 文件的模版，可以用于简单的构建与测试。下面是一个简单的 workflow 文件示例：

name: Test # workflow名称
on: push # 触发此workflow启动的动作
jobs:
  my_first_job: # 第一个job
    name: My first job # job名称
    runs-on: ubuntu-latest # 虚拟环境镜像选择
    steps: # 执行步骤
    - name: checkout # action1
      uses: actions/checkout@master
    - name: Run a single-line script # action2 执行命令行
      run: echo "Hello World!"
  my_second_job:  # 第二个job
    name: My second job
    runs-on: macos-latest
    steps:
    - name: Run a multi-line script
      env:
        MY_VAR: Hello World!
        MY_NAME: P3TERX
      run:
        echo $MY_VAR
        echo My name is $MY_NAME

workflow 语法

(1) name

name 字段是 workflow 的名称。若忽略此字段，则默认会设置为 workflow 文件名。

name: GitHub Actions Demo

(2) on

on 字段指定 workflow 的触发条件，通常是某些事件，比如示例中的触发事件是 push，即在代码 push 到仓库后被触发。on 字段也可以是事件的数组，多种事件触发，比如在 push 或 pull_request 时触发：

on: [push, pull_request]

push 指定分支触发

on:
  push:
    branches:
      - master

push tag 时触发

on:
  push:
    tags:
    - 'v*'

完整的事件列表，请查看官方文档。除了代码库事件，GitHub Actions 也支持外部事件触发，或者定时运行。

(3) jobs

jobs 表示要执行的一项或多项任务。每一项任务必须关联一个 ID (job_id)，比如示例中的 my_first_job 和 my_second_job。job_id 里面的 name 字段是任务的名称。job_id 不能有空格，只能使用数字、英文字母和 - 或_符号，而 name 可以随意，若忽略 name 字段，则默认会设置为 job_id。

当有多个任务时，可以指定任务的依赖关系，即运行顺序，否则是同时运行。

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

上面代码中，job1 必须先于 job2 完成，而 job3 等待 job1 和 job2 的完成才能运行。因此，这个 workflow 的运行顺序依次为：job1、job2、job3。

(4) runs-on

runs-on: ubuntu-18.04

runs-on 字段指定任务运行所需要的虚拟服务器环境，是必填字段，目前可用的虚拟机如下：

Linux
Windows
Macos

(5) steps

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

name：步骤名称。
uses：该步骤引用的action或 Docker 镜像。
run：该步骤运行的 bash 命令。
env：该步骤所需的环境变量。其中 uses 和 run 是必填字段，每个步骤只能有其一。同样名称也是可以忽略的。

这里可以参考使用uses来引用action构建不同语言虚拟环境（如python）
Github Action 设置语言环境示例

action

action 是 GitHub Actions 中的重要组成部分，这点从名称中就可以看出，actions 是 action 的复数形式。它是已经编写好的步骤脚本，存放在 GitHub 仓库中。

对于初学者来说可以直接引用其它开发者已经写好的 action，可以在官方 action 仓库或者

GitHub Marketplace 去获取。此外 Awesome Actions 这个项目收集了很多非常不错的 action。既然 action 是代码仓库，当然就有版本的概念。引用某个具体版本的 action：

steps:
  - uses: actions/setup-node@74bc508 # 指定一个 commit
  - uses: actions/setup-node@v1.2    # 指定一个 tag
  - uses: actions/setup-node@master  # 指定一个分支

快速开始

准备工作：

有一个自己的github 仓库
本地已经拉取git master分支
使用idea打开代码文件（此处演示使用vscode）

创建workflow文件

创建文件test.yml

写入workflow规则

name: Test # workflow名称
on: push # 触发此workflow启动的动作
jobs:
  my_first_job: # 第一个job
    name: My first job # job名称
    runs-on: ubuntu-latest # 虚拟环境镜像选择
    steps: # 执行步骤
    - name: checkout # action1
      uses: actions/checkout@master
    - name: Set python env
      uses: actions/setup-python@v2
      with:
        python-version: '3.x' # Version range or exact version of a Python version to use
    - name: Run a single-line script # action2 执行命令行
      run: echo "Hello World!"
  my_second_job:  # 第二个job
    name: My second job
    runs-on: macos-latest
    steps:
    - name: Run a multi-line script
      env:
        MY_VAR: Hello World!
        MY_NAME: P3TERX
      run:
        echo $MY_VAR
        echo My name is $MY_NAME

push代码

添加代码

git add .github/workflows/test.yml

提交代码

git commit -m "add test.yml"

在这里插入图片描述

push代码

git push

在这里插入图片描述

查看Action

提交后可以在github仓库页面的Action中立刻查看到workflow的记录，左侧有我们Test命名的workflow，橙色标记正在运行的此次提交 add test.yml(命名为commit message)
在这里插入图片描述

查看运行情况

点击此运行实例可以查看到运行的job状态
在这里插入图片描述

点击job进入查看代码日志
在这里插入图片描述

AlwaysDayOne

关注

1
点赞
踩
8

收藏

觉得还不错? 一键收藏
打赏
0
评论
基于 Github Action 的 CI/CD 流程

基于 Github Action 的 CI/CD 流程https://github.com/features/actionsGitHub Marketplace: apps to improve your workflow在大型的开源项目或者软件开发过程中，很多开发者都会去提交PR或者进行代码的 push操作。如果对于每次代码合并都需要项目的核心维护者进行 code review，这项工作是极其困难而且耗时的。因此许多团队都会制定一套代码规范, 然后编写测试用例严格的检查每次代码修改，这样能够
复制链接

扫一扫