github actions--最好的打工仔，帮你干脏活累活！

没头发的卓卓
546 阅读6分钟

前言

经常写代码的朋友们都知道，有很多固定的操作都是在固定的时机执行的（比如更新package.json后需要执行pnpm i），我们有时候却会忘记去执行，这样显然容易导致项目出错，有没有一种办法，把这些固定时机要执行的操作，让项目自动执行呢？

GitHub CLI 简介

GitHub CLI（gh）

GitHub CLI 是 GitHub 提供的命令行工具，旨在帮助开发者直接从终端与 GitHub 平台交互。它提供了一种简洁的方式来执行 GitHub 上的常见任务，如创建仓库、管理问题、处理拉取请求、查看 Actions 状态等。

安装和配置 GitHub CLI：

  1. 安装：

    • Windows：可以通过 winget install gh 或从 GitHub CLI Release 页面下载安装程序。
    • macOS：通过 Homebrew 安装：brew install gh。
    • Linux：可以使用系统的包管理工具，如 apt install gh（Ubuntu）或 dnf install gh（Fedora）。

  2. 配置： 安装完成后，运行以下命令进行认证：

    gh auth login

    然后选择 GitHub 服务（GitHub.com 或 GitHub Enterprise），并通过浏览器授权您的 GitHub 账户。

常见功能和命令：

  • 创建仓库：gh repo create — 用于在 GitHub 上创建新的代码仓库。

  • 管理拉取请求：

    gh pr

    — 用于创建、查看、合并和关闭拉取请求。

    • gh pr list — 列出所有拉取请求。
    • gh pr create — 创建新的拉取请求。
    • gh pr merge — 合并一个拉取请求。

  • 查看问题和讨论：

    gh issue

    — 用于管理 GitHub 问题和讨论。

    • gh issue list — 列出所有问题。
    • gh issue create — 创建新的问题。

  • 与 Actions 集成(这一步要在yml脚本配置完之后)：

    gh actions

    — 查看和管理 GitHub Actions。

    • gh actions list — 列出所有工作流运行。
    • gh actions status — 查看工作流的当前状态。

GitHub Actions

其实GitHub CLI是一个非常广泛的定义，我们这里着重讲actions。GitHub Actions 是 GitHub 提供的一种 CI/CD（持续集成/持续部署）工具，可以用来自动化软件开发生命周期中的各种任务。

编写 GitHub Actions 工作流的关键是创建 YAML 配置文件，它定义了你希望 GitHub 执行的任务、触发时机以及运行环境。下面将介绍如何编写一个简单的 GitHub Actions 配置，并解释各部分内容。

1. GitHub Actions 工作流基础

一个 GitHub Actions 工作流由 触发器、工作（jobs） 和 步骤（steps） 三个主要部分组成。通过配置工作流文件，你可以定义何时执行某个任务、哪些任务需要执行，以及如何执行它们。

  • 触发器（on） ：指定何时触发工作流。例如：push、pull_request、schedule 等。
  • 工作（jobs） ：定义工作流中的任务。每个任务是并行执行的，除非明确指定依赖。
  • 步骤（steps） ：每个工作中的单个操作，可以是命令行命令、GitHub 官方 actions 或自定义脚本。

2. 创建工作流文件

  1. 目录结构：GitHub Actions 配置文件必须位于仓库的 .github/workflows/ 目录中。如果目录或文件不存在，你需要手动创建。

    .github/
  └── workflows/
      └── ci.yml  # 你的工作流配置文件

  2. 工作流文件（YAML）结构： 工作流文件通常包含以下结构：

    • name：工作流的名称（可选）
    • on：定义工作流的触发器（例如：push、pull_request、schedule）
    • jobs：定义要执行的任务及其步骤

3. 简单的 CI 工作流示例

以下是一个简单的 CI 工作流示例，它将在每次推送到 main 分支时自动构建和测试项目。假设你的项目是一个 Node.js 项目。

name: CI Workflow
​
# 触发条件
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
​
# 定义工作流中的任务
jobs:
  build:
    runs-on: ubuntu-latest  # 指定工作流运行的操作系统（例如 Ubuntu）
    
    steps:
      # Step 1: Checkout 仓库代码
      - name: Checkout code
        uses: actions/checkout@v3
​
      # Step 2: 设置 Node.js 环境
      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '16'  # 你希望使用的 Node.js 版本
​
      # Step 3: 安装依赖
      - name: Install dependencies
        run: npm install
​
      # Step 4: 运行测试
      - name: Run tests
        run: npm test

说明：

  • on: 定义触发条件。此示例配置工作流在 push 或 pull_request 事件发生时触发，且只关注 main 分支。
  • jobs: 定义工作流的任务。这里只定义了一个 build 任务，它会在 ubuntu-latest 环境中运行。
  • steps: 每个工作中的具体步骤。这个工作流包含了四个步骤：检出代码、设置 Node.js 环境、安装依赖、运行测试。

4.详解工作流触发器（on）

你可以通过多种方式触发 GitHub Actions 工作流。常用的触发器包括：

a. push（推送代码时触发）
on:
  push:
    branches:
      - main  # 仅当推送到 main 分支时触发
    paths:
      - 'src/**'  # 仅当指定路径下的文件更改时触发
b. pull_request（拉取请求时触发）
on:
  pull_request:
    branches:
      - main
c. workflow_dispatch（手动触发）

手动触发工作流，通常用于测试和开发环境。

on:
  workflow_dispatch:
d. schedule（定时任务）

每隔一定时间自动触发工作流，类似 cron 定时任务。

on:
  schedule:
    - cron: '0 0 * * *'  # 每天午夜12点触发
e. push 和 pull_request 结合
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

5. GitHub Actions 中的常见操作（Actions）

GitHub 提供了很多官方和社区维护的 Actions，你可以在工作流中使用它们，来简化一些常见任务。例如：

  • actions/checkout：用于检出仓库代码。

    - uses: actions/checkout@v3

  • actions/setup-node：用于设置 Node.js 环境。

    - uses: actions/setup-node@v3
  with:
    node-version: '16'

  • docker/build-push-action：用于构建和推送 Docker 镜像。

    - uses: docker/build-push-action@v2
  with:
    context: .
    push: true
    tags: your-docker-image-name

  • aws-actions/configure-aws-credentials：用于配置 AWS 凭证。

    - uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: us-east-1

6. 管理机密和凭证（Secrets）

在工作流中，你可能需要使用机密信息（如 API 密钥、AWS 凭证等）。GitHub 提供了 Secrets 来安全存储这些信息，并在工作流中引用。

  1. 进入 GitHub 仓库的 Settings → Secrets → New repository secret，添加机密。
  2. 在工作流中通过 ${{ secrets.SECRET_NAME }} 引用机密。
- name: Deploy to AWS
  run: aws s3 sync ./build s3://my-bucket
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

7. 更复杂的示例：包括部署

假设你希望在完成构建和测试后，还能自动部署到生产环境。以下是一个更加复杂的工作流示例。

name: CI/CD Workflow
​
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
​
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
​
      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '16'
​
      - name: Install dependencies
        run: npm install
​
      - name: Run tests
        run: npm test
​
  deploy:
    needs: build  # 确保只有在 `build` 工作成功后，才会执行 `deploy` 工作
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
​
      - name: Deploy to production
        run: |
          # 这里可以是你部署应用的命令，比如：
          # 1. 构建静态文件
          # 2. 上传文件到服务器
          # 3. 启动应用
          echo "Deploying to production..."
          # 假设你使用 AWS 或其他服务，可以执行相应的命令

说明：

  • 这个工作流包含两个 jobs：build 和 deploy。
  • deploy 任务在 build 任务成功后执行。通过 needs: build 指定依赖关系，确保 deploy 任务只会在 build 任务成功完成后执行。
  • deploy 部分假设你部署到生产环境，可以在这里执行任何需要的部署步骤。

结语

好了，现在你已经会写github actions脚本了，是时候去实战了！

avatar
文章
阅读
粉丝