AgentSkillsCN

gha-release-pipeline

在设计或升级GitHub Actions发布流水线时使用。重点关注可复现的构建、制品发布，以及来源追溯与SBOM证明。切勿更改产品功能，仅调整发布机制。

SKILL.md
--- frontmatter
name: gha-release-pipeline
description: Use when designing or upgrading a GitHub Actions release pipeline. Focus on reproducible builds, artifact publishing, and provenance/SBOM attestations. Do NOT change product features; only release mechanics.

Principles:

  • •Release from a clean, tagged source of truth (tags/releases)
  • •Use least privilege and environments for production publishing
  • •Prefer OIDC + GitHub artifact attestations for provenance
  • •Make releases reproducible and auditable

Checklist:

  1. •Release trigger model
  • •Choose one:
    • •on: push: tags: ['v*'] (tag-driven releases)
    • •on: release: types: [published] (GitHub Release as source of truth)
    • •workflow_dispatch for manual/promoted releases
  • •Ensure tag naming/versioning policy is explicit (SemVer or repo standard)
  • •Ensure the workflow is deterministic across reruns (same inputs => same outputs)
  1. •Build stages (separate concerns)
  • •Split into jobs/stages:
    • •build & test (no publishing permissions)
    • •package (creates artifacts)
    • •attest (provenance + SBOM)
    • •publish (GitHub Release / Packages / external registries)
  • •Keep publishing credentials isolated to the publish job only
  1. •Artifact production
  • •Produce release artifacts (zip, container image, NuGet/npm packages, etc.)
  • •Store as workflow artifacts for attestation + later publishing
  • •Record checksums (sha256) for key artifacts
  1. •Provenance attestation (GitHub attestations)
  • •Use actions/attest-build-provenance to generate signed provenance for built artifacts
  • •Ensure the attesting job has:
    • •permissions: id-token: write
    • •permissions: attestations: write
    • •minimal contents permission as required (often read)
  1. •SBOM generation + attestation
  • •Generate SBOM for artifacts (SPDX JSON or CycloneDX JSON)
    • •Use tooling appropriate to your ecosystem (.NET, Node, containers)
  • •Use actions/attest-sbom to generate signed SBOM attestations
  • •Keep SBOM generation deterministic and tied to the exact built artifact digest
  1. •Publishing & release notes
  • •Publish artifacts:
    • •GitHub Release assets (preferred default distribution channel)
    • •GitHub Packages / external registries only if needed
  • •Use environments for prod publishing (required reviewers, protected secrets)
  • •Generate release notes from commits/PRs if repo uses that convention
  • •Include migration notes (DB/schema), feature flags, and rollback notes
  1. •Guardrails
  • •Set explicit permissions: everywhere (no implicit broad permissions)
  • •Pin third-party actions to commit SHA
  • •Add concurrency for release runs to avoid parallel publishes
  • •Add timeout-minutes on publish/attest steps
  • •Ensure the pipeline fails if tests fail (no “continue-on-error” on critical steps)

Finish with:

  • •Release workflow outline (triggers + jobs + permissions per job)
  • •What is attested (which artifacts + where to find/verifiy attestations)
  • •What is published (channels + names + versioning)
  • •Any prerequisites (environments, OIDC, required secrets, branch protection)