expo-cicd-workflows by expo/skills
npx skills add https://github.com/expo/skills --skill expo-cicd-workflows帮助开发者编写和编辑 EAS CI/CD 工作流 YAML 文件。
在生成或验证工作流文件之前,请获取这些资源。使用本技能 scripts/ 目录中的获取脚本(使用 Node.js 实现);它使用 ETag 缓存响应以提高效率:
# 获取资源
node {baseDir}/scripts/fetch.js <url>
* 获取此模式是**必需**的
* 验证的权威来源
* 所有作业类型及其必需/可选参数
* 触发器类型和配置
* 运行器类型、虚拟机镜像和所有枚举
2. 语法文档 — https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/syntax.mdx
* 工作流 YAML 语法概述
* 示例和英文说明
* 表达式语法和上下文
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
* 支持的预打包作业类型的文档
* 作业特定参数和输出
请勿依赖记忆中的值;这些资源会随着新功能的添加而更新。
工作流位于 .eas/workflows/*.yml(或 .yaml)。
工作流文件包含以下顶层键:
name — 工作流的显示名称on — 启动工作流的触发器(至少需要一个)jobs — 作业定义(必需)defaults — 所有作业的共享默认值concurrency — 控制并行工作流运行请查阅模式以获取每个部分的完整规范。
使用 ${{ }} 语法表示动态值。模式定义了可用的上下文:
github.* — GitHub 仓库和事件信息inputs.* — 来自 workflow_dispatch 输入的值needs.* — 依赖作业的输出和状态jobs.* — 作业输出(替代语法)steps.* — 自定义作业内的步骤输出workflow.* — 工作流元数据在生成或编辑工作流时:
needs 和 after 中引用的作业在工作流中存在if 条件符合模式的长度限制生成或编辑工作流文件后,请根据模式进行验证:
# 如果缺少依赖项,则安装
[ -d "{baseDir}/scripts/node_modules" ] || npm install --prefix {baseDir}/scripts
node {baseDir}/scripts/validate.js <workflow.yml> [workflow2.yml ...]
验证器会获取最新的模式并检查 YAML 结构。在认为工作流完成之前,请修复所有报告的错误。
当用户询问可用选项(作业类型、触发器、运行器类型等)时,请获取模式并从其中推导答案,而不是依赖可能已过时的信息。
每周安装量
12.1K
仓库
GitHub 星标
1.5K
首次出现
2026年1月19日
安全审计
安装于
github-copilot8.2K
opencode8.0K
codex7.8K
cursor7.7K
gemini-cli7.6K
claude-code7.5K
Help developers write and edit EAS CI/CD workflow YAML files.
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:
# Fetch resources
node {baseDir}/scripts/fetch.js <url>
JSON Schema — https://api.expo.dev/v2/workflows/schema
Syntax Documentation — https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/syntax.mdx
Pre-packaged Jobs — https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/pre-packaged-jobs.mdx
Do not rely on memorized values; these resources evolve as new features are added.
Workflows live in .eas/workflows/*.yml (or .yaml).
A workflow file has these top-level keys:
name — Display name for the workflowon — Triggers that start the workflow (at least one required)jobs — Job definitions (required)defaults — Shared defaults for all jobsconcurrency — Control parallel workflow runsConsult the schema for the full specification of each section.
Use ${{ }} syntax for dynamic values. The schema defines available contexts:
github.* — GitHub repository and event informationinputs.* — Values from workflow_dispatch inputsneeds.* — Outputs and status from dependent jobsjobs.* — Job outputs (alternative syntax)steps.* — Step outputs within custom jobsworkflow.* — Workflow metadataWhen generating or editing workflows:
needs and after exist in the workflowif conditions respect the schema's length constraintsAfter generating or editing a workflow file, validate it against the schema:
# 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.
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.
Weekly Installs
12.1K
Repository
GitHub Stars
1.5K
First Seen
Jan 19, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykWarn
Installed on
github-copilot8.2K
opencode8.0K
codex7.8K
cursor7.7K
gemini-cli7.6K
claude-code7.5K
React 组合模式指南:Vercel 组件架构最佳实践,提升代码可维护性
102,200 周安装