OFFSET偏移
← 全部专题

DOSSIER 23 / 4 篇文章

GitHub Actions 与 CI

把本地检查转为有明确权限、结果和失败证据的持续集成。

从第一篇开始

沿着问题,继续读。

Actions 是事件驱动的自动化系统:先读执行模型,再设计 CI 契约、合并门槛和资源策略,最后审查 Token、Secrets、OIDC、不可信输入与供应链。Nix 主题教学示例把求值、实际构建、输出契约、Actions run 和桌面运行时分别记账。本专题以 CI 为中心;部署、Pages、Packages、大型 Enterprise 治理和自托管 Runner 完整运维仅保留与 CI 直接相连的边界。GitHub UI、套餐、Runner 和 Action 版本会变化,应按当前官方参考和实际平台状态维护。

  1. 01

    先掌握事件到 Step 的执行树,再对照 needs、outputs、matrix、concurrency、cache 与 artifact 的职责。

    GitHub Actions 执行模型

    理解事件、Workflow、Job、Runner 与 Step,以及矩阵、缓存和产物的不同作用。

    阅读文章
  2. 02

    从已有本地命令建立质量门,再看矩阵、缓存和汇总检查;required check 的名称、触发范围与 Pending 状态需要共同验证。

    GitHub Actions CI 配置

    从本地质量门设计 CI,并用稳定的检查状态接入仓库合并规则。

    阅读文章
  3. 03

    先画事件、权限、凭据和 Runner 的信任边界,再阅读 pull_request_target/workflow_run、供应链、日志排查与成本控制。

    GitHub Actions 安全与排障

    沿事件、权限、凭据、Runner 和供应链边界定位 CI 风险与失败。

    阅读文章
  4. 04

    逐段读六变体 Nix workflow 与 flake 输出契约,然后用三层记录模板判断求值、构建、Actions 和桌面证据各能证明什么。

    Nix CI:求值、构建与输出契约

    用六种主题输出的教学示例区分 Nix 求值、构建、Actions 记录和桌面运行证据。

    阅读文章
← 浏览其他专题查看全部文章 ↗