agilelabs-fx-docs main reference/drone-ci-runner-examples.md

Windows / Mac Runner 的 Drone 示例

本页收纳两个偏“桌面端 / 本机工具链”场景的 Drone 示例，分别对应 Windows 64 与 Mac ARM runner。它们重点帮助你理解 runner 选择、脚本收敛方式、平台专属缓存路径，以及哪些字段应保留在 YAML 中，哪些应交给 scripts/ci/*。

正式规范和总体组织方式请先看 Drone CI 配置专题。

适用场景

  • Windows 桌面端或 Electron 应用，需要使用 PowerShell、Windows SDK、安装器或校验和上传流程。
  • macOS 应用构建，需要 Apple Silicon 机器、Bash 脚本、签名准备或生成版本元数据。
  • 项目主要依赖平台本机工具链，而不是统一跑在 Linux 容器中。

Windows 64 runner 示例

适合什么项目

  • Electron Windows 安装包
  • 需要 .ps1 构建脚本的内部工具
  • 必须使用 Windows 原生命令、SDK 或打包工具的项目

推荐 YAML 模板

---
kind: pipeline
type: exec
name: app-win-release

platform:
  os: windows
  arch: amd64

node:
  runner_name: win-build

trigger:
  event:
    - push
    - tag
  ref:
    - refs/heads/main
    - refs/tags/v*

steps:
  - name: env-info
    commands:
      - powershell -NoProfile -ExecutionPolicy Bypass -File scripts/ci/windows-release.ps1 -Action env-info

  - name: clone-submodules
    commands:
      - git submodule update --init --recursive

  - name: restore-config
    commands:
      - powershell -NoProfile -ExecutionPolicy Bypass -File scripts/ci/windows-release.ps1 -Action copy-config

  - name: build
    environment:
      PNPM_STORE_DIR: C:/drone-cache/pnpm-store
      ELECTRON_CACHE: C:/drone-cache/electron
      ELECTRON_BUILDER_CACHE: C:/drone-cache/electron-builder
    commands:
      - powershell -NoProfile -ExecutionPolicy Bypass -File scripts/ci/windows-release.ps1 -Action build

  - name: upload
    commands:
      - powershell -NoProfile -ExecutionPolicy Bypass -File scripts/ci/windows-release.ps1 -Action upload

这个模板要看什么

  • platform.os = windows、platform.arch = amd64、node.runner_name = win-build 是固定 runner 选择。
  • Windows 下建议统一用一个 windows-release.ps1 脚本承接构建逻辑，让 YAML 只表达步骤边界。
  • clone-submodules 这种仓库准备动作适合保留在 YAML 中，因为它本身就是一个清晰的独立步骤。

哪些变量是 runner 相关的

  • PNPM_STORE_DIR
  • ELECTRON_CACHE
  • ELECTRON_BUILDER_CACHE
  • 任何 C:/... 路径

这些变量不能直接抄到 Linux 或 Mac runner。

哪些内容应该抽到脚本

  • 复制配置文件
  • 依赖安装
  • 构建命令组合
  • 生成校验和
  • 上传 OSS / 对象存储 / 制品库

只要一段命令已经跨越“准备、构建、上传”多个职责，就应收敛到脚本。

Mac ARM runner 示例

适合什么项目

  • macOS 应用构建与打包
  • 需要生成版本元数据或 Git 提交摘要的项目
  • 依赖 Apple Silicon 本机环境的构建链

推荐 YAML 模板

---
kind: pipeline
type: exec
name: app-mac-release

platform:
  os: darwin
  arch: arm64

node:
  runner_name: mac-arm-build

trigger:
  event:
    - push
    - tag
  ref:
    - refs/heads/main
    - refs/tags/v*

steps:
  - name: env-info
    commands:
      - bash scripts/ci/mac-release.sh env-info

  - name: clone-submodules
    commands:
      - git submodule update --init --recursive

  - name: generate-version
    commands:
      - bash scripts/ci/mac-release.sh generate-version

  - name: build
    environment:
      PNPM_STORE_DIR: /Users/runner/.pnpm-store
      ELECTRON_CACHE: /Users/runner/.cache/electron
      ELECTRON_BUILDER_CACHE: /Users/runner/.cache/electron-builder
    commands:
      - bash scripts/ci/mac-release.sh build

  - name: upload
    commands:
      - bash scripts/ci/mac-release.sh upload

这个模板要看什么

  • platform.os = darwin、platform.arch = arm64、node.runner_name = mac-arm-build 是 Mac ARM runner 的标准写法。
  • Mac 示例与 Windows 示例保持同样的步骤分层，方便团队在不同平台上使用统一心智模型。
  • 版本元数据生成通常适合独立为一个步骤，便于排查“构建失败”和“版本信息生成失败”是否是同一类问题。

哪些变量是 runner 相关的

  • PNPM_STORE_DIR
  • ELECTRON_CACHE
  • ELECTRON_BUILDER_CACHE
  • 任何 /Users/... 路径

如果项目包含证书、签名、打包缓存目录，也应视为 Mac runner 专属变量。

哪些内容应该抽到脚本

  • Git 提交摘要生成
  • 版本号写入
  • 构建和打包逻辑
  • 上传、签名、归档

文档里只保留“调用哪个脚本做哪类事”，不要把签名或上传细节铺在 YAML 里。

平台示例的共同结论

  • YAML 负责描述“在哪个平台、被什么触发、按什么顺序执行哪些步骤”。
  • 构建脚本负责描述“每一步到底怎么做”。
  • 如果一个项目同时发 Windows 和 Mac 产物，通常应拆成两条 pipeline，而不是让一条 pipeline 混跑多平台。

继续阅读