# Yocto CI Release

> Yocto CI, reproducible build, and release engineering skill for AI coding agents. Use for kas, repo manifests, Git submodules, containerized builds, CI runners, downloads and sstate caches, hash equivalence, PR build gates, QEMU tests, hardware smoke tests, artifact publishing, SDK releases, SBOM/license manifests, release notes, and version pinning.

- Skill: `prashantdivate/yocto-ci-release` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add prashantdivate/yocto-ci-release`
- Raw SKILL.md: https://api.skillmd.com/api/skills/prashantdivate/yocto-ci-release/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: prashantdivate (https://skillmd.com/u/prashantdivate)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/prashantdivate/yocto-ci-release

---


# Yocto CI Release

## Workflow

1. Identify source orchestration: `kas`, `repo`, submodules, manifest repo, or monorepo.
2. Pin every layer and external source needed for reproducibility.
3. Separate caches from build output: `DL_DIR`, `SSTATE_DIR`, hash equivalence, container caches, and artifacts.
4. Build the smallest useful CI matrix: parse, recipe smoke, image, SDK, QEMU/testimage, hardware smoke where available.
5. Publish signed and checksummed artifacts with machine, distro, image, git refs, build config, license data, and SBOM if enabled.
6. Keep secrets out of `local.conf`, logs, and artifacts.

## References

- [ci-release-playbook.md](references/ci-release-playbook.md): CI pipeline patterns, cache strategy, release artifact checklist.

## Guardrails

- Do not use floating branch refs for release builds.
- Do not persist `tmp/` as a cache unless the project explicitly accepts the fragility.
- Do not publish images without checksums and provenance.
- Do not run hardware flashing in CI without explicit device targeting and recovery controls.