depot-github-actions

Audit and migrate GitHub Actions workflows to Depot runners, caches, and container builds.

Updated Aug 2, 2026
One-click install
npx skills add https://github.com/leonardoacosta/skills --skill depot-github-actions-leonardoacosta
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: depot-github-actions
Source: https://github.com/leonardoacosta/skills/tree/main/runtime-kit/skills/depot-github-actions
Command: npx skills add https://github.com/leonardoacosta/skills --skill depot-github-actions-leonardoacosta

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Migrating GitHub Actions workflows to Depot runners, accelerated caches, or container builds risks breaking matrices, reusable-workflow contracts, permissions, and publication pipelines when done as a naive label swap. This Skill enforces an evidence-driven, behavior-preserving migration process that blocks unsafe or unverifiable edits. ## Core Features & Use Cases - Complete workflow graph audit: Inventories triggers, permissions, environments, matrices, reusable callers and callees, expressions, cache steps, builds, and downstream consumers before any change. - Evidence-gated migration: Requires verified Depot App installation, repository scope, runner group, documented runner labels, and project/OIDC/registry evidence only where the affected seam needs it. - Transactional, drift-safe editing: Hashes every target, re-reads before mutation, blocks on concurrent drift, and leaves blocked paths byte-identical. - Security boundaries: Treats pull_request_target as privileged and blocks granting Depot, registry, or publication authority to untrusted execution. - Use Case: A team wants to move a multi-platform container publication workflow to Depot. The Skill traces per-platform digests through artifacts and manifest assembly, verifies the documented integration matches the existing shape, and applies a minimal patch only after all equivalence gates pass. ## Quick Start Audit this repository's GitHub Actions workflows and migrate eligible jobs to Depot runners while preserving all existing behavior.

Frequently Asked Questions about depot-github-actions

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate GitHub Actions jobs to Depot runners?

Map every job's effective runs-on including matrices, expressions, and reusable workflow calls, then verify the Depot App installation covers the repository, the runner group permits it, and the proposed label appears in current Depot documentation. Never infer a label from architecture or an existing GitHub-hosted label.

How do I enable Depot cache acceleration in a GitHub Actions workflow?

Compatible actions using the standard GitHub cache API are accelerated automatically on verified Depot-managed runners, so no workflow edit is required. Preserve existing action pins, keys, restore prefixes, and outputs, and never substitute an invented provider-specific cache action.

Can I add Depot credentials to a pull_request_target workflow?

No. pull_request_target is treated as privileged execution, and if it runs pull-request-controlled content, adding Depot, registry, signing, or publication authority is blocked. The workflow is left byte-identical on that path.

What happens if a workflow changes while a Depot migration patch is being applied?

The migration hashes every target after the audit and compares hashes immediately before editing. If a concurrent modification is detected, the drift blocks the patch and the target files remain byte-identical.

What evidence is required before changing a runner label to Depot?

Runner-only work requires verified Depot App installation, repository access scope, runner group permission, a documented runner label, and the repository's action-pin policy. Project or OIDC identity is only required when another affected step uses it; irrelevant fields are recorded as N/A.

Does Depot migration support multi-platform container builds?

Yes, but the integration must match the workflow's existing shape: Buildx actions use the documented build-push integration, Bake workflows stay Bake, and bespoke shell workflows use Depot setup plus CLI. Per-platform digests, manifest assembly, tags, attestations, and outputs must all be traced and preserved.