# Gha Release Pipeline

> 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.

- Skill: `askaret/gha-release-pipeline` (Agent Skill)
- Install (CLI): `npx skillmds@latest add askaret/gha-release-pipeline`
- Raw SKILL.md: https://api.skillmd.com/api/skills/askaret/gha-release-pipeline/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: askaret (https://skillmd.com/u/askaret)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/askaret/gha-release-pipeline

---


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)

2) 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

3) 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

4) 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`)

5) 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

6) 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

7) 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)