之前在维护自建代码托管平台时有一个需求始终绕不开团队里的 iOS / macOS 项目需要跑构建、跑测试但 Linux 服务器上没法直接编译 Apple 平台产物。后来 Gitea 1.19 起开始支持 Gitea Actions自托管 CI/CD 终于可以完全脱离第三方平台。不过真正把 Gitea Actions 跑在 Apple 硬件上时还是踩了不少坑包括 runner 注册、label 匹配、签名证书、钥匙串权限等。本文把整套落地过程整理成一份可直接参考的教程从原理解析到实战配置都有适合正在搭建自托管 CI、或准备把 Apple 设备接入 Gitea Actions 的开发者。1. Gitea Actions 与 Apple 硬件组合的价值1.1 Gitea Actions 是什么Gitea Actions 是 Gitea 自带的 CI/CD 功能语法上兼容 GitHub Actions 的 workflow 写法。开发者可以在仓库中存放.gitea/workflows/*.yaml文件定义构建、测试、发布等流水线当 push、pull request、tag 等事件触发时Gitea 会调度 runner 执行对应的 job。与 Jenkins、GitLab CI 相比Gitea Actions 的优势在于轻量、部署简单、与 Gitea 仓库深度集成。对于中小团队、个人开发者、内网环境的持续集成需求来说它是性价比很高的方案。1.2 为什么需要 Apple 硬件Linux 上可以跑 Docker、Java、Python、Node.js 等大部分自动化任务但遇到 Apple 平台构建时Linux 环境无能为力。典型场景包括场景说明iOS App 构建需要 Xcode、iOS SDK只能运行在 macOSmacOS 应用打包需要 Xcode、Swift、Objective-C 工具链Apple Silicon 原生编译需要 arm64 架构的 macOS 设备证书签名与公证调用 Apple 签名工具和公证服务多平台测试需要在真实 macOS 环境中跑 UI 测试或集成测试如果在自托管 Gitea 上做这些任务最直接的办法就是把 runner 部署到一台 macOS 设备上。这里所说的 Apple 硬件包括 Mac mini、Mac Studio、MacBook Pro 等芯片可以是 Apple SiliconM 系列也可以是 Intel 芯片。1.3 适用读者与前置了解这篇文章适合以下读者已经在用 Gitea想搭建自托管 CI/CD 的开发者。团队里有 iOS / macOS 项目需要自动构建和测试的工程师。想把闲置 Mac 变成构建机器的个人开发者。对 GitHub Actions 熟悉、想迁移到 Gitea Actions 的开发者。阅读本文前建议你先了解 Gitea 的基本使用比如创建仓库、管理用户如果对 GitHub Actions 的 workflow 语法有所了解上手会更快。2. 环境准备与方案选型2.1 硬件与系统要求在 Apple 硬件上运行 Gitea Actions本质上是在 macOS 上安装并运行 act_runner然后让 runner 与 Gitea 服务端通信。硬件需求不高最低配置只要 macOS 系统能正常跑 Xcode 即可。推荐配置芯片Apple SiliconM1/M2/M3/M4或 Intel。内存16GB 起步构建 iOS 工程时 Xcode 比较吃内存。磁盘建议 256GB 以上Xcode 和 DerivedData 会占用大量空间。系统macOS 13、14、15 均可需保持 Xcode 与系统版本兼容。需要注意如果你是拿 MacBook 当 runner建议接电源并设置为“合盖不休眠”否则跑长任务时系统睡眠会导致 job 中断。2.2 Gitea 服务端版本Gitea Actions 从 Gitea 1.19 开始作为实验功能引入在后续版本中逐步完善。为了减少配置问题建议使用 1.21 之后的稳定版本并使用官方 act_runner 作为 runner 程序。版本要求汇总组件说明Gitea 服务端1.21 或更高版本启用 Actions 功能act_runnerGitea 官方 runner持续更新系统macOS 12建议 13架构amd64Intel或 arm64Apple Silicon如果你正在用旧版本 Gitea请先升级再配置 Actions版本过旧会导致 runner 与服务端协议不兼容。2.3 Runner 方案选择在 Apple 硬件上执行 Gitea Actionsrunner 方案只有一种官方路径act_runner。act_runner 是 Gitea 官方维护的 runner 程序支持 Linux、Windows、macOS。它默认使用 Docker 执行 job但 macOS 上无法直接使用 Docker 的 Linux 容器来编译 Xcode 项目。因此在 macOS 设备上我们通常使用host模式让 job 直接在当前 macOS 环境中执行。这意味着在 Apple 硬件上的 runner 和典型 Linux runner 有区别项目Linux runnermacOS runner执行环境默认 Docker 容器默认宿主机直接执行隔离性较好较差工具链依赖镜像预装依赖宿主机 Xcode/Homebrew典型用途通用构建Apple 平台构建2.4 示例环境说明本文以以下环境作为示例Gitea 服务端域名git.example.com。Apple 硬件一台 Mac miniApple SiliconmacOS Sonoma。Runner 程序act_runner。示例仓库ios-demo。实际部署时请根据你的 Gitea 地址、token、仓库名进行替换。3. Gitea Actions 的核心工作原理3.1 控制面与执行面Gitea Actions 分为两部分控制面Gitea 服务端负责解析 workflow、创建 job、记录状态。执行面runner 负责接收 job、执行命令、上传日志和产物。当开发者 push 代码后Gitea 服务端会检查仓库.gitea/workflows/目录下的 YAML 文件。每份 workflow 可以定义多个 job每个 job 指定runs-on标签。服务端将一个或多个 job 放入调度队列等待具备对应标签的 runner 认领。3.2 act_runner 注册机制act_runner 第一次运行前需要注册。注册会拿到一个运行时 ID 和密钥此后 runner 通过轮询或长连接方式向 Gitea 服务端请求任务。注册方式有两种手动注册在命令行中指定 Gitea 实例地址和注册 token。配置注册通过配置文件指定环境变量简化多 runner 部署。注册 token 在 Gitea 后台的“站点管理 - Actions - Runner”页面可以生成。一个 token 可以注册多个 runner但一般建议一个 runner 一个 token便于管理。3.3 Label 与 workflow 匹配每个 runner 注册时可以声明 label比如macos-latest、macos-arm64、self-hosted。workflow 中runs-on指定的 label 需要与 runner 的 label 匹配否则 job 一直处于等待状态。常见 label 建议Label适用场景macos-latestmacOS 通用构建macos-arm64Apple Silicon 原生构建macos-x64Intel Mac 构建self-hosted通用标签多平台 runner 可共用在多个 label 同时存在时runner 会优先匹配满足条件的工作。如果 workflow 写了macos-latest但 runner 只注册了macos-arm64任务将无法被认领。4. 实战在 Apple 设备上部署 act_runner4.1 创建专用用户出于安全考虑不建议用个人日常账号直接跑 runner。虽然 act_runner 在 macOS 上需要访问 Xcode、Homebrew 等工具推荐创建一个独立账号。创建步骤打开“系统设置 - 用户与群组”。新建用户建议名字为gitea-runner。设置管理员权限安装依赖方便或根据安全策略设为普通用户。用该用户登录一次完成 Homebrew、Xcode 等工具初始化。如果你的 Mac 只作为构建机器也可以直接把 runner 放在开机启动项中让gitea-runner用户自动运行。4.2 下载 act_runneract_runner 的二进制可以从 Gitea 官方 Releases 页面获取。在 macOS 终端中执行# 先确定 CPU 架构 uname -m如果是 Apple Silicon输出arm64如果是 Intel输出x86_64。然后下载对应架构的压缩包# 以 arm64 为例请替换为最新版本号 wget https://gitea.com/gitea/act_runner/releases/download/v0.2.11/act_runner_0.2.11_darwin_arm64.zip unzip act_runner_0.2.11_darwin_arm64.zip sudo mv act_runner /usr/local/bin/ sudo chmod x /usr/local/bin/act_runner如果 wget 不存在可以用 curlcurl -L -o act_runner.zip https://gitea.com/gitea/act_runner/releases/download/v0.2.11/act_runner_0.2.11_darwin_arm64.zip注意请根据你的实际最新版本替换版本号。较新的 act_runner 版本可能提供了不同的压缩包命名以官方 Releases 页面为准。4.3 获取注册 token登录 Gitea 管理后台进入“站点管理 - Actions - Runner”点击“创建新 Runner”。Gitea 会展示一段注册命令和注册 token。注册 token 形如xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx这个 token 是 runner 和 Gitea 服务端建立信任关系的关键凭证不要提交到代码仓库也不要泄露给无关人员。4.4 注册 runner 到 Gitea在 macOS 终端中执行注册命令act_runner register --instance https://git.example.com --token xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --name mac-mini-arm64 --labels macos-latest,macos-arm64,self-hosted --no-interactive参数说明参数含义--instanceGitea 服务端地址--token上一步获取的注册 token--namerunner 名称便于后台识别--labelsrunner 支持的标签逗号分隔--no-interactive非交互式注册适合脚本化注册完成后会在当前目录生成.runner文件该文件保存了 runner 的 ID 和密钥。后续启动 runner 时程序会优先读取.runner文件完成鉴权。4.5 创建配置文件act_runner 默认行为是使用 Docker 作为执行环境。但在 macOS 上我们需要改成 host 模式即直接在宿主机执行 job。创建配置文件config.yamllog: level: info runner: file: .runner capacity: 2 envs: A_APPLE_ENV: 1 container: privileged: true force_pull: false valid_volumes: - /Users/gitea-runner/work - /Users/gitea-runner/.ssh host: workdir_parent: /Users/gitea-runner/work关键配置runner.capacity该 runner 同时执行的 job 数量。Apple 硬件上建议设置为 1 或 2避免多个 Xcode 构建同时运行导致系统资源耗尽。host.workdir_parenthost 模式下 job 的工作目录父路径。valid_volumes允许挂载的宿主机路径列表。需要说明act_runner 在不同版本中配置字段可能略有差异。如果配置项不生效可以先运行act_runner generate-config生成默认配置再在此基础上修改。4.6 启动 runner 并验证前台启动便于查看日志act_runner daemon --config config.yaml如果输出类似于INFO[0000] Starting runner daemon INFO[0000] Runner registered successfully INFO[0000] Fetching new job...说明 runner 已连接 Gitea 服务端。此时回到 Gitea 后台的 Actions Runner 页面可以看到 runner 状态为在线。为了减少终端依赖可以把 runner 注册为后台服务。macOS 上可以使用 launchd创建~/Library/LaunchAgents/com.gitea.act_runner.plist?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keyLabel/key stringcom.gitea.act_runner/string keyProgramArguments/key array string/usr/local/bin/act_runner/string stringdaemon/string string--config/string string/Users/gitea-runner/config.yaml/string /array keyRunAtLoad/key true/ keyKeepAlive/key true/ keyWorkingDirectory/key string/Users/gitea-runner/string keyStandardOutPath/key string/Users/gitea-runner/runner.log/string keyStandardErrorPath/key string/Users/gitea-runner/runner.err.log/string /dict /plist然后加载服务launchctl load ~/Library/LaunchAgents/com.gitea.act_runner.plist launchctl start com.gitea.act_runner注意如果该 plist 位于gitea-runner用户的 LaunchAgents 目录需要用该用户登录后启动如需系统级开机自启请放到/Library/LaunchDaemons/并注意权限设置。5. 编写第一个 macOS workflow5.1 仓库目录结构在 Gitea 仓库中创建 Actions 工作流目录ios-demo/ ├── .gitea/ │ └── workflows/ │ └── build.yml ├── MyApp.xcodeproj ├── MyApp/ └── README.md5.2 基础 workflow 示例下面是一个最简单的 macOS 构建 workflow。它会在 push 和 pull request 时触发在 macOS runner 上执行 xcodebuild 编译。# 文件路径.gitea/workflows/build.yml name: iOS Build on: push: branches: - main pull_request: jobs: build: runs-on: macos-latest steps: - name: Checkout uses: actions/checkoutv4 - name: Show Xcode version run: | xcodebuild -version swift --version - name: Build iOS App run: | xcodebuild \ -project MyApp.xcodeproj \ -scheme MyApp \ -sdk iphonesimulator \ -configuration Debug \ build这个 workflow 的核心步骤actions/checkoutv4拉取仓库代码。xcodebuild -version检查 Xcode 环境。xcodebuild build执行模拟器环境编译。由于 runner 是 host 模式所有命令都直接在 macOS 上执行因此xcodebuild命令可以正常工作。5.3 保存构建产物构建完成后如果需要上传 .app 或 .ipa 文件可以使用actions/upload-artifact。- name: Upload Artifact uses: actions/upload-artifactv4 with: name: MyApp path: | build/Debug-iphonesimulator/MyApp.app注意path需要匹配你 Xcode 的实际输出路径。可以在 workflow 中添加-derivedDataPath ./build固定输出目录便于收集产物。更新后的 build 步骤- name: Build iOS App run: | xcodebuild \ -project MyApp.xcodeproj \ -scheme MyApp \ -sdk iphonesimulator \ -configuration Debug \ -derivedDataPath ./build \ build5.4 运行与验证将 workflow 文件提交并推送到 Gitea 仓库git add .gitea/workflows/build.yml git commit -m feat: add iOS build workflow git push origin main在 Gitea 仓库的 Actions 页面可以看到本次 push 触发的流水线记录。点击记录可以查看 steps 日志。如果 runner 在线且 label 匹配job 会被快速认领并开始执行。首次执行需要下载 checkout 插件耗时取决于网络环境。6. 进阶代码签名、公证与钥匙串处理6.1 为什么签名在 CI 里更复杂iOS / macOS 产物发布前通常需要代码签名。签名依赖证书、描述文件或 Provisioning Profile而这些私密文件不应该硬编码在 workflow 中。比较规范的做法是把证书放在 Gitea 的 Secrets 中在 workflow 运行时导入钥匙串。6.2 添加 Secrets 到 Gitea进入仓库的“设置 - Actions - Secrets”新增以下变量Secret 名称内容APPLE_CERT_BASE64开发者证书 .p12 文件经过 Base64 编码后的字符串APPLE_CERT_PASSWORD证书导出时的密码PROVISIONING_PROFILE_BASE64描述文件经过 Base64 编码后的字符串生成 Base64 编码的命令base64 -i Certificates.p12 cert_base64.txt base64 -i MyApp.mobileprovision profile_base64.txt注意不要在本地直接查看或复制 p12 内容避免泄露文件使用后建议安全删除。6.3 workflow 中导入证书在正式 build 之前先执行证书导入步骤。- name: Import Apple Certificate run: | echo $APPLE_CERT_BASE64 | base64 --decode /tmp/Certificates.p12 echo $PROVISIONING_PROFILE_BASE64 | base64 --decode /tmp/MyApp.mobileprovision mkdir -p ~/Library/MobileDevice/Provisioning\ Profiles cp /tmp/MyApp.mobileprovision ~/Library/MobileDevice/Provisioning\ Profiles/ security create-keychain -p $APPLE_CERT_PASSWORD build.keychain security default-keychain -s build.keychain security unlock-keychain -p $APPLE_CERT_PASSWORD build.keychain security import /tmp/Certificates.p12 \ -k build.keychain \ -P $APPLE_CERT_PASSWORD \ -T /usr/bin/codesign \ -T /usr/bin/xcodebuild security set-key-partition-list \ -S apple-tool:,apple:,codesign: \ -s -k $APPLE_CERT_PASSWORD build.keychain env: APPLE_CERT_BASE64: ${{ secrets.APPLE_CERT_BASE64 }} APPLE_CERT_PASSWORD: ${{ secrets.APPLE_CERT_PASSWORD }} PROVISIONING_PROFILE_BASE64: ${{ secrets.PROVISIONING_PROFILE_BASE64 }}这段脚本的作用将 Secrets 中的 Base64 内容解码为证书文件和描述文件。描述文件放入 Xcode 读取目录。创建临时钥匙串build.keychain。将证书导入该钥匙串并授权codesign与xcodebuild访问。设置钥匙串分区列表避免签名时出现权限弹窗。6.4 签名与导出 ipa签名步骤因项目而异常见的 xcodebuild 导出命令- name: Archive and Export run: | xcodebuild \ -project MyApp.xcodeproj \ -scheme MyApp \ -configuration Release \ -archivePath ./build/MyApp.xcarchive \ archive xcodebuild \ -exportArchive \ -archivePath ./build/MyApp.xcarchive \ -exportPath ./build/export \ -exportOptionsPlist ExportOptions.plistExportOptions.plist需要放在仓库中或由脚本动态生成。内容示例?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keymethod/key stringapp-store/string keysigningStyle/key stringmanual/string keyteamID/key stringYOUR_TEAM_ID/string /dict /plist需要根据你的发布方式修改method例如app-store、ad-hoc或development。6.5 公证Notarization如果你的 macOS 应用要分发到公网还需要 Apple 公证。Gitea Actions 的 macOS runner 中可以直接调用xcrun notarytool。- name: Notarize run: | xcrun notarytool submit ./build/export/MyApp.pkg \ --keychain-profile notary-profile \ --wait需要提前在 runner 机器上保存 App Store Connect API 密钥xcrun notarytool store-credentials notary-profile \ --apple-id your-apple-id \ --team-id YOUR_TEAM_ID \ --password app-specific-password或者使用 API Key 方式xcrun notarytool store-credentials notary-profile \ --key AuthKey_XXXXXXXX.p8 \ --key-id KEY_ID \ --issuer ISSUER_ID这里要特别说明公证需要真实有效的 Apple 开发者账号凭证。如果没有对应凭证可以跳过公证步骤只做本地签名。7. 常见问题与排查思路7.1 Runner 不在线现象Gitea 后台 Runner 列表显示离线。排查步骤确认 act_runner 进程是否在运行。查看 runner 日志确认是否出现网络错误。检查.runner文件是否存在且有效。确认--instance地址从 runner 机器上可以访问。确认 Gitea 版本与 act_runner 版本兼容。解决思路网络不通检查防火墙、代理设置。token 失效重新注册。地址错误在浏览器中打开 Gitea 地址确认能正常访问。7.2 Job 一直处于等待状态现象workflow 已触发但 job 长时间不执行。最常见原因runs-on标签与 runner 的 labels 不匹配。排查步骤查看 runner 注册时的 labels。查看 workflow 中runs-on值。将两者调整一致。示例如果 runner 注册为--labels macos-arm64workflow 必须写runs-on: macos-arm64如果写的是macos-latest需要修改 workflow或者重新注册 runner 时加上macos-latest标签。7.3 找不到 Xcode 或命令不存在现象job 执行时提示xcode-select: error: tool xcodebuild requires Xcode。原因runner 使用的 macOS 用户没有配置 Xcode 命令行工具或 Xcode 路径未设置。解决思路sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer xcodebuild -version如果 Xcode 安装路径不是标准路径需要先确认xcode-select -p7.4 Runner 执行 job 时提示权限不足现象脚本中需要访问某些目录、钥匙串或系统设置但 runner 账号没有权限。原因macOS 对应用和脚本的访问控制比 Linux 更严格。解决思路将 runner 账号设为管理员。在“系统设置 - 隐私与安全性”中授予终端或 runner 进程相应权限。使用 LaunchDaemon 运行 runner而不是 LaunchAgent以获得更高权限。需要权衡安全性给予太多权限可能带来风险建议在专用构建机上执行。7.5 多个 job 并发导致构建失败现象多个 iOS 构建同时进行时出现资源耗尽、Xcode 冲突、编译失败。原因runner capacity 设置过高。解决思路将config.yaml中runner.capacity调整为 1runner: file: .runner capacity: 1然后重启 act_runner。对于 Apple 硬件稳定性比并发数更重要。7.6 常见问题速查表问题现象常见原因解决思路Runner 离线网络不通、token 失效检查网络重新注册Job 等待中label 不匹配调整 runs-on 或 runner labels找不到 xcodebuildXcode 路径未设置执行 xcode-select --switch证书导入失败密码错误、格式不对重新导出 p12检查 Base64签名报错钥匙串未解锁使用 security unlock-keychain构建速度慢并发过高降低 capacityMac 休眠导致任务中断节能设置设置合盖不休眠接电源8. 生产环境最佳实践8.1 独立构建账号与最小权限尽量为 runner 创建独立 macOS 用户不要使用管理员个人账号。如果团队内多个项目共用一台 Mac可以按项目或按团队创建多个 runner配合不同 label 区分。生产环境建议runner 用户只安装构建所需工具。Xcode、Homebrew、CocoaPods、SwiftLint 等统一版本管理。定期清理缓存和旧 DerivedData。避免在 runner 上手动执行其他操作防止环境被污染。8.2 Secret 管理与敏感信息保护所有证书、密码、API Key 必须放到 Gitea Secrets 中不要写在 workflow 文件或项目代码里。官方虽然提供 Secrets 能力但还需要注意保密边界Secrets 只在运行 job 时注入环境变量。不要在 step 中直接echo $SECRET打印密钥。证书解码后存入/tmp或临时目录脚本结束后主动删除。典型的清理命令rm -f /tmp/Certificates.p12 /tmp/MyApp.mobileprovision security delete-keychain build.keychain8.3 工作目录与缓存策略host 模式下job 会直接在当前机器上操作文件系统。为了避免多任务相互干扰建议固定workdir_parent路径。每次 job 前清理工作目录。使用 Gitea Actions Cache 保存依赖缓存例如 Homebrew 缓存、CocoaPods 缓存、SPM 缓存。缓存操作可以使用actions/cache- name: Cache SPM uses: actions/cachev3 with: path: ~/Library/Caches/org.swift.swiftpm key: ${{ runner.os }}-spm-${{ hashFiles(Package.resolved) }}8.4 Apple Silicon 与 Intel 双架构管理如果团队同时有 Apple Silicon 和 Intel Mac建议分别注册不同 labelmacos-arm64对应 Apple Silicon runner。macos-x64对应 Intel runner。workflow 中根据构建需求选择合适的 label。如果项目需要同时产出两种架构的产物可以在 workflow 中使用矩阵策略。jobs: build: runs-on: ${{ matrix.runs_on }} strategy: matrix: include: - runs_on: macos-arm64 arch: arm64 - runs_on: macos-x64 arch: x64注意矩阵任务会创建多个 job需要确认对应的 runner 都处于在线状态。8.5 定时维护与资源清理macOS 作为构建机长期运行时磁盘和缓存会不断膨胀。建议在 workflow 中增加定时清理 job或使用 launchd 定时任务清理以下目录~/Library/Developer/Xcode/DerivedData~/Library/Caches/org.swift.swiftpm~/Library/Developer/Xcode/Archives/Users/gitea-runner/work清理命令示例rm -rf ~/Library/Developer/Xcode/DerivedData/* rm -rf ~/Library/Caches/org.swift.swiftpm/*如果担心误删正在使用的文件可以先统计磁盘占用du -sh ~/Library/Developer/Xcode8.6 可观测性与告警Gitea Actions 页面自带日志和状态展示但在生产环境中建议额外监控 runner 进程使用脚本定时检测act_runner daemon进程是否存活。失败时通过邮件、钉钉、Slack 等发送告警。定期检查 Actions 队列中是否有长时间 pending 的 job。一个简单的进程检查脚本#!/bin/bash if pgrep -x act_runner /dev/null; then echo act_runner is running else echo act_runner is down # 发送告警并重启 /usr/local/bin/act_runner daemon --config /Users/gitea-runner/config.yaml fi8.7 版本锁定与更新策略act_runner 和 Gitea 服务端需要保持兼容。升级之前先查看官方 Release Notes避免版本差异导致通信失败。更新步骤下载新版本 act_runner。停止旧进程。替换二进制文件。启动并验证 runner 在线状态。运行一个测试 workflow 确认功能正常。如果 Gitea 服务端版本较旧不要盲目升级 act_runner务必查看官方文档中的版本兼容说明。9. 小结从“能跑到”到“跑得好”现在再回顾一下整条链路Gitea 服务端负责调度act_runner 部署到 Apple 硬件上注册时声明好 labelworkflow 中通过runs-on找到对应 runner然后在真实 macOS 环境中执行 Xcode 构建、签名、公证、产物上传。这套方案解决的是“ Apple 平台产物无法在 Linux CI 上构建”的核心问题同时也带来了新的工程挑战runner 与宿主机共享环境隔离性比 Docker 弱对机器的管理要求更高。在实际项目中建议按以下优先级推进先打通最小 workflow确认 runner 能跑通xcodebuild -version。再加入项目构建和测试。然后处理签名与描述文件。最后补充缓存、清理、监控、告警机制。不要把全部精力花在一开始就追求完美流水线上。CI/CD 系统的价值在于稳定可重复而不是功能越多越好。如果在配置过程中遇到具体报错比如 label 不匹配、钥匙串权限、签名失败欢迎回到文章对应的章节按清单排查。这套配置在我的团队里已经稳定运行了一段时间相信按这个思路操作你也可以把 Apple 硬件变成 Gitea Actions 的可靠构建节点。