Windmill CLIwmill实战指南安装配置、工作区管理、脚本运行与全量同步【免费下载链接】windmillOpen-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.项目地址: https://gitcode.com/GitHub_Trending/wi/windmillWindmill CLI命令名wmill是与 Windmill 平台交互的命令行工具覆盖从安装配置、工作区切换、脚本与流程运行到资源推送、工作区双向同步、Shell 补全乃至本地开发测试的全链路操作。本文将基于仓库内 cli/README.md 官方文档结合 cli/src/main.ts 的 CLI 实现与 cli/examples/ 的真实示例文件为你呈现一份可直接上手、可复现验证的完整使用手册。一、安装与升级wmill通过 npm 以全局方式安装npm install -g windmill-cli安装完成后仓库内的 cli/package.json 将wmill命令映射到src/main.tsbin: { wmill: src/main.ts }即 CLI 的实际入口。后续如需升级到最新版本直接执行wmill upgrade该命令底层通过NpmProvider检查 npm 上windmill-cli包的最新版本并执行更新见 cli/src/main.ts 中UpgradeCommand的实现。若升级失败CLI 会提示可尝试sudo或重新执行npm uninstall windmill-cli npm install -g windmill-cli。也可以随时用wmill version查看当前 CLI 版本在已配置活动工作区的情况下它还会额外显示后端Backend版本号方便排查版本不匹配问题。全局选项wmill提供了若干全局选项作用于所有子命令定义见 cli/src/main.ts选项说明--workspace workspace指定目标工作区覆盖默认工作区--debug/--verbose显示调试/详细日志--show-diffs同步时显示 diff 信息可能暴露敏感信息--token token指定 API Token覆盖已存储的 Token--base-url baseUrl指定 API 的 base URL使用时必须同时提供--token和--workspace且不再使用本地已配置的 remote/workspace--config-dir configDir指定自定义配置目录覆盖WMILL_CONFIG_DIR环境变量与默认的~/.config位置HEADERS环境变量为所有请求附加自定义请求头格式如HEADERSh1: v1, h2: v2--base-url常用于对接自定义部署的 Windmill 实例配合--token与--workspace可在不依赖本地工作区配置的情况下直接访问远端。二、工作区管理工作区Workspace是 Windmill 中组织脚本、流程、资源的基本单元。首次使用前运行wmill workspace add即可按交互提示添加并激活一个工作区也可以直接参考实例工作区设置页给出的指引。CLI 会在本地持久化工作区与远端地址的映射。切换到其他工作区wmill workspace switch workspace_name查看当前工作区信息、管理 remote 配置等均可通过wmill workspace子命令完成不提供子命令时默认列出所有工作区。三、运行脚本与流程运行脚本或流程是wmill最高频的用法wmill script run u/username/path/to/script wmill flow run u/username/path/to/flow其中u/username/...是 Windmill 中的路径约定u/表示用户空间也可以使用f/表示文件夹空间。运行时通过--data传入输入参数支持三种形式内联 JSON 字符串--data {name: Henri}从文件读取--data filename从标准输入读取--data -同时兼容 Curl 风格简写-d -表示从 stdin 读取-d filename表示从文件读取。脚本执行期间Flow 的步骤Steps与日志Logs会自动流式输出到终端无需额外参数。下面这张图展示了通过wmill script run u/henri/well_wishers_script -d {name: Henri}传入参数并实时观察执行结果的过程从执行输出可以看到CLI 会依次显示作业排队、环境准备如下载 Deno 标准库模块、执行完成等阶段最终打印脚本的返回结果整个交互与 Web 端运行体验一致。关于脚本运行的底层实现参数解析、路径校验、作业轮询与日志流式输出可进一步阅读 cli/src/commands/script/script.ts。四、推送资源、脚本与更多wmill可以把本地定义好的脚本、流程、资源、变量、资源类型、文件夹等规范specification推送到 Windmill 实例。各类型的文件格式请参考仓库内的 cli/examples/ 目录脚本见 cli/examples/u/admin/fib/fib.script.json元数据文件包含summary、description、schema输入参数 JSON Schema、is_template、lock依赖锁、kindscript/failure/trigger/command/approval等字段脚本代码本体如fib.ts与之同名同目录存放资源见 cli/examples/u/admin/example.resource.json通过value定义资源内容resource_type指定类型并支持$var:g/all/not_secret这样的变量引用语法变量见 cli/examples/u/admin/example.variable.json流程见 cli/examples/u/admin/example.flow.json文件夹见 cli/examples/f/my_folder/folder.meta.json资源类型见 cli/examples/example.resource-type.json。五、工作区同步wmill sync提供本地目录与远端工作区之间的双向同步能力# 将远端工作区内容拉取到本地 wmill sync pull # 将本地内容推送到远端工作区 wmill sync push官方文档强烈建议在同步时使用--yaml选项以 YAML 而非 JSON 作为文件编码格式YAML 即将成为默认格式wmill sync pull --yaml wmill sync push --yaml推送单个文件如果只想推送某个单独的对象无需遵循特定目录布局或文件名约定可以直接在运行时指定远端路径wmill type push file_name remote_name例如wmill script push ./local/fib.ts u/admin/fib wmill resource push ./local/example.resource.json u/admin/my_resource其中type为对象类型如script、flow、resource、variable、resource-type、folder等remote_name是推送到远端的路径。这种按需推送方式同样支持各类对象适合快速部署单个变更。六、列出对象与获取帮助所有子命令都遵循不带子命令即列出的约定。例如直接运行wmill script会列出当前工作区中的全部脚本同理wmill flow、wmill resource、wmill variable等会列出对应类型对象。部分命令还支持额外的过滤选项通过--help查看wmill script --help七、用户管理管理员可以在命令行直接管理用户wmill user add email wmill user remove email wmill user不提供子命令的wmill user会列出当前工作区的用户列表。其实现位于 cli/src/commands/user/user.ts对应user子命令的注册见 cli/src/main.ts。八、拉取整个工作区除了同步目录外wmill pull可以直接将整个远端工作区内容拉取到本地不要求先建立同步目录结构wmill pull这在迁移工作区、备份或本地开发场景下非常实用一次性把脚本、流程、资源、变量、调度等全部内容落地为本地文件。九、Shell 补全wmill开箱即用地支持 shell 补全底层由cliffy/command提供见 cli/package.json 的依赖声明。生成补全脚本的命令为wmill completions shellBash将以下内容追加到~/.bashrcsource (wmill completions bash)Fish将以下内容追加到~/.config/fish/config.fishsource (wmill completions fish | psub)Zsh将以下内容追加到~/.zshrcsource (wmill completions zsh)配置生效后即可在终端中享受子命令、参数乃至远端路径的自动补全。十、命令全景wmill提供的能力矩阵从 cli/src/main.ts 的注册代码看wmill已内置 40 余个子命令除本文重点介绍的脚本/流程/工作区/同步/用户/补全外还包括资源与数据resource、variable、resource-type、datatable、object-storage、ducklake调度与触发schedule、trigger应用与流程app、flow、pipelineCI/CD 与同步sync、gitsync-settings、hub管理与运维instance、workers、worker-groups、queues、jobs、job、group、token、audit、folder、protection-rules、config、docsAI 与工程化init、refresh、lint、dev、dependencies、generate-metadata任意子命令都可以通过wmill cmd --help获取详细的参数说明。十一、开发者进阶AI 引导内容定制wmill init用于初始化项目。对于需要定制 AI 引导AI Guidance内容的开发者CLI 支持通过内部环境变量覆盖默认生成内容而无需修改仓库中的默认模板WMILL_INIT_AI_SKILLS_SOURCE/path/to/custom/skills wmill init --use-default WMILL_INIT_AI_SKILLS_SOURCE/path/to/custom/skills WMILL_INIT_AI_AGENTS_SOURCE/path/to/AGENTS.md wmill init --use-default WMILL_INIT_AI_SKILLS_SOURCE/path/to/custom/skills WMILL_INIT_AI_CLAUDE_SOURCE/path/to/CLAUDE.md wmill init --use-default该机制与 ai_evals/ 下的基准测试 CLI 使用同一条引导内容写入路径因此wmill init与基准测试工具生成的工程引导结构完全一致统一包含四类产物AGENTS.mdCLAUDE.md.agents/skills/*.claude/skills/*十二、开发者进阶lint 与 YAML 校验wmill lint用于对本地对象文件做静态校验。其校验器并非来自 npm 发行版而是直接从同仓库的windmill-yaml-validator包源码导入因此其 JSON Schema 始终与当前代码仓库检出的 OpenAPI 规范保持一致见 windmill-yaml-validator/README.md。如果修改了openflow.openapi.yaml或backend/windmill-api/openapi.yaml需要重新生成校验 schema可执行npm --prefix ../windmill-yaml-validator run gen即windmill-yaml-validator包的gen脚本bun install也会通过其preinstall脚本自动执行一次。十三、本地开发与测试前置条件在本地运行wmill的测试套件需要本地 PostgreSQL默认连接串postgres://postgres:changemelocalhost:5432已安装 Rust 工具链运行测试完整功能模式默认bun test test/CI 模式最小特性集跳过依赖企业版的 EE 测试CI_MINIMAL_FEATUREStrue bun test test/相关环境变量变量说明CI_MINIMAL_FEATURES设为true时跳过依赖 EE 的测试DATABASE_URLPostgreSQL 连接串EE_LICENSE_KEY企业版功能所需的 License Key仓库内测试用例位于 cli/test/覆盖了工作区管理、脚本推送/运行、同步、资源管理、补全等核心路径可作为深入理解 CLI 行为的第一手参考。结语从npm install -g windmill-cli的分钟级上手到wmill sync push/pull的整库同步、wmill completions的终端体验优化再到wmill init/wmill lint/bun test覆盖的开发者工作流wmill把 Windmill 平台的主要管理操作完整地搬到了命令行。结合 cli/examples/ 中的真实对象定义与 cli/src/main.ts 的全局选项设计你可以把它无缝嵌入脚本、CI/CD 流水线与本地开发循环中实现脚本即代码、配置即文件的声明式运维。【免费下载链接】windmillOpen-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.项目地址: https://gitcode.com/GitHub_Trending/wi/windmill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考