Apple硬件运行Gitea Actions：架构、排错与稳定实践

在 Apple 硬件上跑 Gitea Actions表面看只是把 CI 的执行节点从 Linux 换成 macOS实际会遇到几个完全不同的坑Apple Silicon 的 arm64 架构、Docker 镜像平台不匹配、host 模式下的权限与 PATH、签名时需要用钥匙串、Mac 休眠导致任务卡住。这篇文章从 Gitea Actions 的架构讲起先说明服务器与执行器怎么分工再在一台 Mac 上把 Gitea、act_runner 和第一个 Workflow 完整跑通最后补充生产环境中最常见的排错路径和稳定性建议。核心目标只有一个让读者在自己的 Apple 硬件上稳定运行 Gitea Actions而不是只停留在“能安装、能注册”的层面。1. Gitea Actions 在 Apple 硬件上要解决的三个关键问题1.1 Gitea 与 Runner 的分工Gitea 是一个自托管的 Git 服务。Actions 是它内置的 CI/CD 能力但“内置”不代表 Gitea 进程自己执行任务。真实工作方式是Gitea 负责接收仓库事件根据.gitea/workflows目录下的 YAML 文件生成 job再把 job 分配给已经注册好的 runner。Runner 从 Gitea 拉取任务在本地执行最后把日志、状态码和产物信息回传给 Gitea。所以Actions 实际是一条调度链路Gitea 服务器控制平面负责任务生成、状态展示、日志存储。act_runner执行平面负责拉取任务并真正运行命令。Workflow 文件声明任务怎么跑放在哪个仓库触发条件是什么。理解这个分工后很多问题就清楚了。比如用户在一台 Mac 上安装 Gitea并不代表 job 一定在 Mac 上执行。如果注册的 runner 在另一台 Linux 服务器上job 就会在 Linux 上跑。反过来Gitea 服务器可以放在远程 Linux 机器上Mac 只作为 runner 节点这样才能真正利用 Apple 硬件的构建能力。1.2 Apple 硬件为什么值得单独处理Apple Silicon 芯片是 arm64 架构在终端输入uname -m会返回arm64。如果你通过 Rosetta 运行终端可能返回x86_64。这个差异直接影响构建参数、依赖安装和 Docker 镜像拉取。在 Linux CI 上最常见的是 x86_64 环境工具链和缓存镜像都围绕这个架构准备。而在 Apple 硬件上两个典型场景是 Linux 服务器很难替代的编译 macOS 原生程序运行 macOS 测试处理.app或.dmg打包