ef285b5c97
* fix: stabilize validation and tests on Windows * test: add Windows smoke coverage for skill activation * refactor: make setup_web script CommonJS * fix: repair aegisops-ai frontmatter * docs: add when-to-use guidance to core skills * docs: add when-to-use guidance to Apify skills * docs: add when-to-use guidance to Google and Expo skills * docs: add when-to-use guidance to Makepad skills * docs: add when-to-use guidance to git workflow skills * docs: add when-to-use guidance to fp-ts skills * docs: add when-to-use guidance to Three.js skills * docs: add when-to-use guidance to n8n skills * docs: add when-to-use guidance to health analysis skills * docs: add when-to-use guidance to writing and review skills * meta: sync generated catalog metadata * docs: add when-to-use guidance to Robius skills * docs: add when-to-use guidance to review and workflow skills * docs: add when-to-use guidance to science and data skills * docs: add when-to-use guidance to tooling and automation skills * docs: add when-to-use guidance to remaining skills * fix: gate bundle helper execution in Windows activation * chore: drop generated artifacts from contributor PR * docs(maintenance): Record PR 457 sweep Document the open issue triage, PR supersedence decision, local verification, and source-only cleanup that prepared PR #457 for re-running CI. --------- Co-authored-by: sickn33 <sickn33@users.noreply.github.com>
101 lines
3.8 KiB
Markdown
101 lines
3.8 KiB
Markdown
---
|
|
name: expo-cicd-workflows
|
|
description: Helps understand and write EAS workflow YAML files for Expo projects. Use this skill when the user asks about CI/CD or workflows in an Expo or EAS context, mentions .eas/workflows/, or wants help with EAS build pipelines or deployment automation.
|
|
allowed-tools: "Read,Write,Bash(node:*)"
|
|
risk: unknown
|
|
source: community
|
|
version: 1.0.0
|
|
license: MIT License
|
|
---
|
|
|
|
# EAS Workflows Skill
|
|
|
|
Help developers write and edit EAS CI/CD workflow YAML files.
|
|
|
|
## When to Use
|
|
|
|
- You need to create, edit, or validate `.eas/workflows/*.yml` files for an Expo project.
|
|
- The task involves EAS build pipelines, deployment automation, workflow triggers, or Expo CI/CD configuration.
|
|
- You need schema-backed workflow guidance rather than relying on stale memorized syntax.
|
|
|
|
## Reference Documentation
|
|
|
|
Fetch these resources before generating or validating workflow files. Use the fetch script (implemented using Node.js) in this skill's `scripts/` directory; it caches responses using ETags for efficiency:
|
|
|
|
```bash
|
|
# Fetch resources
|
|
node {baseDir}/scripts/fetch.js <url>
|
|
```
|
|
|
|
1. **JSON Schema** — https://api.expo.dev/v2/workflows/schema
|
|
- It is NECESSARY to fetch this schema
|
|
- Source of truth for validation
|
|
- All job types and their required/optional parameters
|
|
- Trigger types and configurations
|
|
- Runner types, VM images, and all enums
|
|
|
|
2. **Syntax Documentation** — https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/syntax.mdx
|
|
- Overview of workflow YAML syntax
|
|
- Examples and English explanations
|
|
- Expression syntax and contexts
|
|
|
|
3. **Pre-packaged Jobs** — https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/pre-packaged-jobs.mdx
|
|
- Documentation for supported pre-packaged job types
|
|
- Job-specific parameters and outputs
|
|
|
|
Do not rely on memorized values; these resources evolve as new features are added.
|
|
|
|
## Workflow File Location
|
|
|
|
Workflows live in `.eas/workflows/*.yml` (or `.yaml`).
|
|
|
|
## Top-Level Structure
|
|
|
|
A workflow file has these top-level keys:
|
|
|
|
- `name` — Display name for the workflow
|
|
- `on` — Triggers that start the workflow (at least one required)
|
|
- `jobs` — Job definitions (required)
|
|
- `defaults` — Shared defaults for all jobs
|
|
- `concurrency` — Control parallel workflow runs
|
|
|
|
Consult the schema for the full specification of each section.
|
|
|
|
## Expressions
|
|
|
|
Use `${{ }}` syntax for dynamic values. The schema defines available contexts:
|
|
|
|
- `github.*` — GitHub repository and event information
|
|
- `inputs.*` — Values from `workflow_dispatch` inputs
|
|
- `needs.*` — Outputs and status from dependent jobs
|
|
- `jobs.*` — Job outputs (alternative syntax)
|
|
- `steps.*` — Step outputs within custom jobs
|
|
- `workflow.*` — Workflow metadata
|
|
|
|
## Generating Workflows
|
|
|
|
When generating or editing workflows:
|
|
|
|
1. Fetch the schema to get current job types, parameters, and allowed values
|
|
2. Validate that required fields are present for each job type
|
|
3. Verify job references in `needs` and `after` exist in the workflow
|
|
4. Check that expressions reference valid contexts and outputs
|
|
5. Ensure `if` conditions respect the schema's length constraints
|
|
|
|
## Validation
|
|
|
|
After generating or editing a workflow file, validate it against the schema:
|
|
|
|
```sh
|
|
# Install dependencies if missing
|
|
[ -d "{baseDir}/scripts/node_modules" ] || npm install --prefix {baseDir}/scripts
|
|
|
|
node {baseDir}/scripts/validate.js <workflow.yml> [workflow2.yml ...]
|
|
```
|
|
|
|
The validator fetches the latest schema and checks the YAML structure. Fix any reported errors before considering the workflow complete.
|
|
|
|
## Answering Questions
|
|
|
|
When users ask about available options (job types, triggers, runner types, etc.), fetch the schema and derive the answer from it rather than relying on potentially outdated information.
|