GitHub Actions
GitHub Actions 是 GitHub 提供的持续集成（CI）和持续交付（CD）平台，旨在帮助开发者自动化构建、测试和部署代码。
1. 什么是 GitHub Actions？
GitHub Actions 是一种自动化工具，允许开发者直接在 GitHub 上构建、测试和部署代码。
它通过 YAML 文件定义工作流，可以根据仓库中的事件触发这些工作流，例如创建、合并或关闭拉取请求。
2. GitHub Actions 的基本概念
2.1. 工作流（Workflow）
- 一次持续集成运行的过程。工作流文件存放在
.github/workflows目录中。 - 文件名可以任意取，但后缀名必须是
.yml或.yaml。
2.2. 任务（Job）
- 一个工作流由一个或多个任务组成，每个任务可以并行或串行运行。每个任务在一个独立的虚拟机或容器中运行。
2.3. 步骤（Step）
- 每个任务由多个步骤组成，每个步骤执行一个具体的操作。步骤可以是运行命令、调用脚本或使用预定义的操作。
2.4. 操作（Action）
- 步骤中执行的具体命令或脚本，可以是预定义的操作或自定义脚本。
- 操作可以从 GitHub Marketplace 获取，也可以自己编写。
3. 如何创建 GitHub Actions 工作流
3.1. 创建工作流文件
在你的 GitHub 仓库中，导航到 .github/workflows 目录。如果该目录不存在，可以手动创建。然后在该目录下创建一个以 .yml 为后缀的 YAML 文件，例如 ci.yml。
3.2. 定义工作流
在 YAML 文件中定义工作流的名称、触发事件和具体步骤。以下是一个简单的示例：
name: CI
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v2
with:
node-version: '14'
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
这个工作流在每次推送或拉取请求时触发，执行以下步骤：
- 检出代码：使用
actions/checkout@v2操作从仓库中检出代码。 - 设置 Node.js 环境：使用
actions/setup-node@v2操作设置 Node.js 版本。 - 安装依赖：运行
npm install命令安装项目依赖。 - 运行测试：运行
npm test命令执行测试。
注：
actions/checkout与actions/setup-node目前已更新至 v4，Node.js 建议使用 20 LTS，示例保留原文写法，新项目建议用新版本。
3.3. 使用预配置的工作流模板
GitHub 提供了一些预配置的工作流模板，可以按原样使用或根据需要进行自定义。这些模板涵盖了常见的编程语言和框架，例如 Node.js、Python、Java 等。
3.4. 监控和故障排除
GitHub Actions 提供了详细的日志记录功能，帮助你监控工作流的运行状态并进行故障排除。你可以在 GitHub 仓库的 “Actions” 选项卡中查看每次工作流运行的详细日志。
4. 示例：部署静态网站
以下是一个部署静态网站的示例工作流：
name: Deploy static website
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Build website
run: |
npm install
npm run build
- name: Deploy to GitHub Pages
uses: peaceiris/actions-gh-pages@v3
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
publish_dir: ./public
这个工作流在每次推送到 main 分支时触发，执行以下步骤：
- 检出代码：使用
actions/checkout@v2操作从仓库中检出代码。 - 构建网站：运行
npm install和npm run build命令构建静态网站。 - 部署到 GitHub Pages：使用
peaceiris/actions-gh-pages@v3操作将构建后的文件部署到 GitHub Pages。
5. Git Tag
[!NOTE]
electron-builder 默认只在有 Git tag 时才会发布。确保在准备发布新版本时创建一个新的 Git tag：
git tag v1.0.0 # 使用实际的版本号
git push --tags
完成这些步骤后，重新运行你的 CI/CD 流程应该就能成功发布到 GitHub 了。
如果你只是想在本地构建而不发布，可以使用：
npm run build
而不是 npm run dist。这样就只会构建应用而不会尝试发布。
5.1. 环境变量
您使用的命令中，“dandan” 不是一个有效的 EnvironmentVariableTarget。
PowerShell 中的 SetEnvironmentVariable 方法需要一个有效的目标，可以是 Process、User 或 Machine。
根据您想要设置环境变量的范围，您可以使用以下命令之一：
5.2. 为当前进程设置（临时）
$env:GH_TOKEN = "ghp_YourTokenHere"
5.3. 为当前用户设置（持久化）
[Environment]::SetEnvironmentVariable("GH_TOKEN", "ghp_YourTokenHere", "User")
5.4. 为系统设置（持久化，需要管理员权限）
[Environment]::SetEnvironmentVariable("GH_TOKEN", "ghp_YourTokenHere", "Machine")
安全提示：不要在命令或文档中直接暴露 GitHub Personal Access Token，这是非常敏感的信息，不应以明文形式存储或分享（原文中的真实令牌已替换为占位符）。如已泄露，请立即到 GitHub 设置中撤销该令牌。
6. GH_TOKEN 一直报错时的有效方法
6.1. 使用个人访问令牌
如果其他方法都不起作用，可以尝试使用个人访问令牌：
git remote set-url origin https://<your-access-token>@github.com/baoyu0/InsightWave.git
注意：pat 后面的 @ 符号。
git remote set-url origin https://[email protected]/baoyu0/InsightWave
6.2. 版本号
版本号用于标识软件的不同版本，帮助用户和开发者了解软件的更新和变化。
6.3. 版本号格式
通常使用语义化版本号（Semantic Versioning），格式为：主版本号.次版本号.修订号（例如：1.0.0）。
6.4. 保持一致性
frontend/package.json 中的 version 字段和 Git 标签应该保持一致，这样可以确保发布的版本与代码实际版本相匹配。
6.5. 自动化版本管理
为了简化这个过程，我们可以使用一个 npm 包来自动管理版本号。以下是具体步骤：
-
安装 version-bump-prompt 包：
npm install --save-dev version-bump-prompt -
在 frontend/package.json 中添加以下脚本：
"scripts": { "version": "version-bump-prompt --commit --tag --push" } -
当您要发布新版本时，只需运行：
npm run version这个命令会提示您选择要增加的版本号类型（主版本、次版本或修订版本），然后自动更新 package.json 中的版本号，创建一个提交，添加一个 Git 标签，并推送到远程仓库。
6.6. 在 CI/CD 中使用版本号
您的 CI/CD 工作流程已经配置为在推送带有 v 前缀的标签时触发发布流程。使用上述方法创建的标签会自动触发这个流程。
6.7. 手动管理（如果您更喜欢手动控制）
如果您不想使用自动化工具，您可以手动更新 frontend/package.json 中的 version 字段，然后创建一个匹配的 Git 标签：
git tag v1.0.0
git push origin v1.0.0
这将触发 CI/CD 工作流程，构建应用程序并创建一个新的 GitHub Release。
通过这种方式，您可以确保 package.json 中的版本号与 Git 标签保持同步，从而使您的发布过程更加一致和可靠。
6.8. release 排查
根据您提供的截图和 CI/CD 配置文件，构建过程成功完成，但 release 步骤被跳过了。这是正常的行为，因为 release 作业只在特定条件下运行。让我解释一下原因和如何触发 release：
6.9. release 作业的触发条件
在 ci-cd.yml 文件中，release 作业有一个条件：
if: startsWith(github.ref, 'refs/tags/v')
这意味着只有当推送的是以 “v” 开头的标签时，才会触发 release 作业。
6.10. 当前的推送
从截图中可以看到，这次运行是由普通的推送触发的（“baoyu0 pushed”），而不是标签推送。
6.11. 如何触发 release
要触发 release 作业，您需要创建并推送一个新的版本标签。例如：
git tag v1.0.1
git push origin v1.0.1
6.12. 自动版本更新
您的工作流程中包含了自动更新版本的步骤：
- name: Update version
run: |
cd frontend
npm version patch -m "Bump version to %s [skip ci]"
git config --global user.email "[email protected]"
git config --global user.name "GitHub Actions"
git push
git push --tags
这个步骤会自动增加补丁版本号并创建一个新的标签。但是，由于提交消息中包含 [skip ci]，它不会触发新的 CI 运行。
6.13. 建议
如果您希望自动创建的标签能触发 release，可以移除 [skip ci] 部分。
或者，您可以手动创建和推送标签来触发 release 过程。
6.14. 检查 release
即使 release 作业被跳过，构建的 artifacts 仍然被上传了。您可以在 GitHub Actions 的 “Artifacts” 部分找到它们。
6.15. 总结
当前的行为是正常的。如果您想创建一个新的 release，请推送一个新的版本标签，或者修改自动版本更新步骤以允许它触发新的 CI 运行。
7. 总结
GitHub Actions 是一个强大的工具，可以显著提高开发效率，通过自动化构建、测试和部署流程，帮助团队更快地交付高质量的软件。希望本教程能帮助你快速上手 GitHub Actions，开始自动化你的开发工作流。