107 lines
4.3 KiB
Markdown
107 lines
4.3 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.
|
|
risk: unknown
|
|
source: https://github.com/expo/skills/tree/main/plugins/expo/skills/expo-cicd-workflows
|
|
source_repo: expo/skills
|
|
source_type: official
|
|
date_added: 2026-07-01
|
|
license: MIT
|
|
license_source: https://github.com/expo/skills/blob/main/LICENSE
|
|
---
|
|
|
|
# EAS Workflows Skill
|
|
## When to Use
|
|
|
|
Use this skill when you need 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.
|
|
|
|
|
|
Help developers write and edit EAS CI/CD workflow YAML files.
|
|
|
|
## Reference Documentation
|
|
|
|
Fetch these resources before generating or validating workflow files. First resolve this skill's directory, then use the fetch script in its `scripts/` directory. It is implemented using Node.js and caches responses using ETags for efficiency:
|
|
|
|
```bash
|
|
# Fetch resources
|
|
node <skill-dir>/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 "<skill-dir>/scripts/node_modules" ] || npm install --prefix <skill-dir>/scripts
|
|
|
|
node <skill-dir>/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.
|
|
|
|
## Limitations
|
|
|
|
- Use this skill only when the task clearly matches its upstream product or API scope.
|
|
- Verify commands, API behavior, pricing, quotas, credentials, and deployment effects against current official documentation before making changes.
|
|
- Do not treat generated examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
|