Github Actions 工作流入门

📝 备注

GitHub 文档是一种持续集成和持续交付 (CI/CD) 平台，可用于自动执行生成、测试和部署管道。
常见的用途包括：代码推送后自动运行测试、合并 PR 后自动部署到服务器、定时执行数据抓取脚本等。

1. 基本概念

首先我们来看看一些基本的概念。

Workflow (工作流)：一套完整的自动化流程配置，定义了什么时候做什么事。一个 .yml 文件 = 一个 Workflow。
Event (事件)：触发工作流的特定行为，即什么时候。例如 push 代码、pull_request 合并等。
Job (任务)：一个工作流由一个或多个任务组成，默认情况下，任务是并行执行的。
Step (步骤)：每个任务由多个步骤组成，它们会按顺序执行。
Action (动作)：可复用的封装好的操作，来自 GitHub 官方、第三方或自己编写，通过 uses 引用。例如 actions/checkout 就是一个官方动作，专门用于检出代码。
Runner (运行器)：执行工作流的服务器环境。GitHub 提供了免费的虚拟服务器（Ubuntu, Windows, macOS），你也可以使用自己的服务器。

简单来说我们可以使用 GitHub Actions 指定在什么时候、干什么事。
例如我们都知道github是代码托管平台，而push代码仓库其实就是一个什么时候，而这个时候我们就可以指定工作流来完成一些工作。既然要做什么事，那就肯定要有一个工作的平台，也就是服务器。而这个工作流可以有多个工作，而一个工作又有多个步骤(比如某些指令某些行动)

2. 基本使用

2.1 创建文件

在 GitHub 上的存储库中，创建 .github/workflows 目录中名为 xxx.yml 的工作流文件,名字可以任意，文件后缀为yml或yaml。

2.2 编写工作流文件

先来看个示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


name: CI-Web

on: # 指的是什么时候触发工作流  
  push:
    branches: # branches 上传到什么分支时触发 
      - main
    paths: # 进一步过滤， 在 zx-picture-frontend 目录下的文件变化才触发
      - zx-picture-frontend/** 

pull_request:
    branches:
     - main            # 只在目标分支为 main 的 PR 上触发（即要合并进 main 的 PR）
    types:
     - opened          # PR 被创建时
      - synchronize     # PR 有新的提交推入时
      - reopened        # PR 被重新打开时

jobs:
  npm-build:  		 # Job 的 ID（自定义名称，同一 Workflow 内唯一）
  	name: npm-build工作 # Job 的显示名称（可选，不填则显示 Job ID）
    runs-on: ubuntu-latest  # 指定运行环境
    steps:
      - name: 复制仓库代码到虚拟机服务器当中  # Step 的名称（可选，用于在日志中标识该步骤）
        uses: actions/checkout@v4 
      - name: 安装依赖
        run: npm install # 相当于你亲自在服务器（虚拟机）的命令行里执行一条命令
      - name: 项目打包
        run: npm run build

2.3 uses 的语法解析

这里单独说说uses,因为实际上这个用的非常多。其作用就是调用一个预先打包好的 Action。

users 的值通常遵循 owner/repo@version 的格式。

owner/repo：托管这个 Action 代码的 GitHub 仓库。第一个是组织、第二个是仓库。例如：actions/checkout表示这是由 actions 这个组织（GitHub 官方）开发的 checkout 仓库。
@version：指定使用的 Action 版本。

3.总结

GitHub Actions 是一个功能强大且灵活的自动化平台，是现代软件开发不可或缺的一环。