Woodpecker CI 术语体系与核心架构：从 Pipeline、Workflow、Step 到事件模型

CI/CDDevOps【免费下载链接】woodpeckerWoodpecker is a simple, yet powerful CI/CD engine with great extensibility.项目地址https://gitcode.com/gh_mirrors/wo/woodpecker点击查看免费下载本篇技术指南以 Woodpecker CI当前仓库 docs/versioned_docs/version-2.8/20-usage/15-terminology/index.md的官方术语表为核心骨架系统梳理 Woodpecker 中 Server、Agent、Pipeline、Workflow、Step、Event 等核心概念的精确定义与层级关系并结合仓库源码验证事件常量、依赖并行调度DAG与命名约定等底层实现。读完本文你将能准确理解 Woodpecker 的架构分工、看懂工作流 YAML 的各个组成部分并掌握与社区一致的术语使用规范为阅读 工作流语法 与 多工作流编排 打下共同语言基础。核心术语表GlossaryWoodpecker 的文档体系围绕一套统一术语展开。以下是官方 Glossary 的完整条目按“系统组件 → 执行单元 → 数据与配置 → 扩展机制”的逻辑分组整理系统组件Server、Agent 与 CLIWoodpecker CI围绕 Woodpecker 的整个项目名称。Woodpecker一个开源工具用于在你的代码上执行 Pipeline。ServerWoodpecker 中负责接收来自 Forge 的 Webhook、编排 Agent、并回传状态给 Forge 的组件同时对外提供 API 与 Web UI用于管理和配置。在仓库中服务端主体位于 server/ 目录包括 API 路由server/router/、调度器server/scheduler/与队列server/queue/。Agent使用特定后端例如 Docker、Kubernetes、Local执行 Pipeline具体来说是一个或多个 Workflow的组件。Agent 通过gRPC连接 Server——这一连接机制在 agent/rpc/dial.go 与 agent/rpc/client_grpc.go 中实现对应的 RPC 协议定义见 rpc/proto/woodpecker.proto。CLIWoodpecker 的命令行界面用于管理 Server、在本地执行 Pipeline 以调试/测试以及执行 Lint Pipeline 等任务。CLI 实现位于 cli/本地执行能力由 cli/exec/exec.go 提供Lint 功能见 cli/lint/lint.go。执行单元Pipeline、Workflow 与 StepPipeline在代码上执行的一系列 Workflow 的序列由事件Event触发。Workflow作为 Pipeline 一部分执行的一串 Step 与 Service。Workflow 由YAML 文件表示每个 Workflow 拥有自己隔离的 Workspace以及额外的资源例如 Docker 场景下的共享网络。StepsWorkflow 内的单个命令、动作或任务。这三个概念是 Woodpecker 的执行层级核心其关系在下文“Pipeline、Workflow 与 Step 的关系”小节中有专门图示说明。数据与配置Code、Repos、Forge、Workspace、Commit 等Code指 Forge 所用版本控制系统所跟踪的文件。ReposRepository 的简称代码存放的存储位置。Forge托管 Repository 的平台或服务。Woodpecker 支持 GitHub、GitLab、Gitea、Bitbucket 等多种 Forge各适配实现见 server/forge/。WorkspaceWorkflow 所有 Step 之间共享的一个文件夹内含仓库代码以及此前 Step 产生的所有数据。Event触发 Pipeline 执行的事件例如 Forge 事件push或由用户在 UI 手动触发的manual事件。Commit代码的一个确定状态通常与 Git 等版本控制系统关联。Matrix一种配置选项允许 Workflow 针对 Matrix 中的每个值各执行一次。详细语法见 矩阵工作流。Container命令执行的轻量、隔离环境。扩展机制Service、Plugins 与 Service extensionService从 Workflow 开始一直执行到其结束的一种 Step同 Workflow 内的其他 Step 可以通过网络按名称访问它。例如数据库、缓存等伴随型依赖通常以 Service 形式提供用法见 Services。PluginsPlugins 是为 Workflow 中的 Step 提供预定义动作或命令的扩展可通过 settings 配置。插件生态与用法见 插件概述。Service extensionWoodpecker 的部分内部服务如密钥存储 secrets storage、配置获取器 config fetcher可以通过 Service extension 替换为自定义实现。执行语义Dependency 与 StatusDependencyWorkflow 之间可以相互依赖如果可能它们会被并行执行。StatusStep 或 Workflow 执行完毕后由其内部命令的退出码决定的结果状态Workflow 结束时其状态会回传给 Forge。Woodpecker 总体架构上图为官方 architecture.svg 所描绘的总体架构其分工与 Glossary 中的定义一一对应Forge托管平台向Server推送 Webhook 事件Server负责 Webhook 处理、Pipeline 创建与调度调度器实现见 server/scheduler/impl.go并通过 gRPC 将任务分发给AgentAgent使用所选后端Docker、Kubernetes、Local 等见 pipeline/backend/实际执行 Workflow并将执行日志与状态回传 ServerServer汇总状态回写 Forge同时通过 API/Web UI 向管理员与用户提供管理与配置入口。需要补充的一点是Agent 并不直接执行整个 Pipeline而是执行其中的一个或多个 Workflow同一 Pipeline 的不同 Workflow 可以由不同 Agent 并行承担这正体现了 Workflow 级并行与隔离的设计意图。Pipeline、Workflow 与 Step 的关系官方 pipeline-workflow-step.svg 直观展示了三者关系Pipeline 是顶层执行单元包含一个或多个 Workflow每个 Workflow 又包含若干 Step以及 Service。这一层级在仓库的数据模型中也有完整对应Pipeline 模型server/model/pipeline.go以Event、Status、Commit、Branch、Ref等字段描述一次完整的执行并通过Workflows []*Workflow挂载下属工作流Workflow 模型server/model/workflow.go记录Name、State、AgentID、Platform、Environ等信息并通过Children []*Step挂载步骤Running()/Failing()方法用于判定其运行中/失败状态判断是否为多工作流 Pipeline 的方法IsMultiPipeline()直接以len(p.Workflows) 1为依据server/model/pipeline.go。关于Workflow 之间的依赖与并行Glossary 中的 “Dependency” 条目指出 Workflow 可相互依赖且尽可能并行。仓库中该逻辑由 DAG有向无环图编译器实现位于 pipeline/frontend/yaml/compiler/dag.go当步骤或工作流声明depends_on时编译器会按依赖关系分阶段编译compileByDependsOn无依赖的节点可进入并行执行对应的测试用例见 pipeline/frontend/yaml/compiler/compiler_test.go。多工作流编排的完整说明见 Workflows。Pipeline 事件EventsPipeline 由事件触发。Woodpecker 官方定义的事件清单如下push当提交被推送到分支时触发。pull_request当 Pull Request 被打开或向其中推送新提交时触发。pull_request_closed当 Pull Request 被关闭或合并时触发。tag当标签被推送时触发。release当创建 release、pre-release 或 draft 时触发。可借助 evaluate 配合 内置环境变量 做进一步过滤。manual当用户在 UI 中手动触发 Pipeline 时触发。cron当 Cron 任务执行时触发。这些事件在源码中对应WebhookEvent类型的常量定义server/model/const.go除上述七种外还包含pull_request_metadata与deployment事件常量字符串值说明EventPushpush分支推送EventPullpull_requestPR 打开/新提交EventPullClosedpull_request_closedPR 关闭/合并EventPullMetadatapull_request_metadataPR 元数据变更EventTagtag标签推送EventReleaserelease创建 release/pre-release/draftEventDeploydeploymentForge 部署事件EventCroncronCron 任务触发EventManualmanualUI 手动触发每个事件的合法性由WebhookEvent.Validate()校验server/model/const.go。Pipeline 模型中的Event字段即为此类型服务端据此决定 Pipeline 的创建与后续流程见 server/pipeline/create.go。命名约定Conventions为避免社区与文档中出现一词多义Woodpecker 官方明确了以下术语使用规范环境变量*_LINK应写作*_URL代码中应使用URL()而非Link()。使用pipelines而非此前的builds。使用steps而非此前的jobs。高级环境变量通常无需用户设置统一使用WOODPECKER_EXPERT_前缀。最后一条约定在仓库配置中有实际落地WOODPECKER_EXPERT_FORGE_OAUTH_HOST与WOODPECKER_EXPERT_WEBHOOK_HOST即分别在 cmd/server/flags.go 与 cmd/server/flags.go 中作为服务器端高级参数被解析印证了“供专家场景使用、普通用户无需关心”的定位。延伸阅读理解上述术语后建议按以下顺序继续深入工作流语法Workflow SyntaxStep、Service、when条件、evaluate表达式与 Workspace 的完整定义多工作流Workflows工作流间依赖、状态行与流程控制矩阵工作流MatrixMatrix 配置的展开语义插件PluginsStep 级扩展机制Forge 概览、Docker 后端 与 Local 后端对应 Forge 与 Agent 后端概念。赞分享CI/CDDevOps【免费下载链接】woodpeckerWoodpecker is a simple, yet powerful CI/CD engine with great extensibility.项目地址https://gitcode.com/gh_mirrors/wo/woodpecker点击查看免费下载相关推荐Woodpecker CI 术语表与核心架构从 Agent、Pipeline、Workflow 到 Step 的完整技术解读Woodpecker CI 术语表与核心架构从 Agent、Pipeline、Workflow 到 Step 的完整技术解读 Woodpecker 是一套开源CI/CDDevOpsKedro 核心术语全解析从 Data Catalog、Pipeline 到 Runner 与 Session 的概念体系Kedro 核心术语全解析从 Data Catalog、Pipeline 到 Runner 与 Session 的概念体系 本指南以 Kedro 官方术语表数据工程工作流自动化掌握Dify工作流HTTP请求配置3个实用技巧帮你轻松连接外部API掌握Dify工作流HTTP请求配置3个实用技巧帮你轻松连接外部API 还在为如何在Dify工作流中调用外部API而烦恼吗HTTP请求是连接Dify与外部世界示例工程上一篇Add TradingView Alerts Tool支持的交易所与交易对获取方法大全下一篇Theatre微交互设计模式常见交互场景解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考