- CI/CD
- DevOps
【免费下载链接】woodpecker
Woodpecker is a simple, yet powerful CI/CD engine with great extensibility.
本篇指南以 Woodpecker CI/CD 引擎的 workflow 配置文件语法为核心，系统讲解steps、services、workspace、clone等顶层区块的完整写法，深入剖析when条件过滤、depends_on依赖编排、failure失败策略与labels调度匹配等高级特性。读完本文，你将掌握从零编写一份可投入生产使用的.woodpecker.yaml，理解每一步在 yaml 前端解析器 与 编译器 中的底层执行逻辑，并能利用条件执行、矩阵构建与 DAG 依赖实现精细化 CI 流程控制。
Workflow 是什么
Workflow（工作流）区块定义了一系列用于构建、测试和部署代码的步骤（steps）。默认情况下，这些步骤按照定义的顺序串行执行：如果某一步返回非零退出码，则该 workflow 以及整个 pipeline 会立即终止并返回错误状态。
steps: - name: backend image: golang commands: - go build - go test - name: frontend image: node commands: - npm install - npm run test - npm run build[!NOTE] 唯一的例外是带有
status: [failure]条件的步骤（见下文 status 过滤），它保证在失败的运行中仍被执行。
[!NOTE] Woodpecker 支持 YAML 1.2 的大部分特性，同时为向后兼容保留部分 1.1 的行为（底层使用 go-yaml v3 库解析）。
步骤命名
上例定义了两个步骤frontend和backend，它们的名称完全由你决定。name字段是可选的——如果省略，步骤会被自动编号。除了列表形式，步骤也可以用字典（映射）形式命名：
steps: backend: image: golang commands: - go build - go test frontend: image: node commands: - npm install - npm run test - npm run build从源码角度看，steps、services、clone都被定义为ContainerList（见 workflow.go），即由Container组成的列表；每个容器的字段在 container.go 中通过 YAML tag 明确定义，包括name、image、pull、commands、entrypoint、directory、settings、environment、depends_on、when、failure、detach、volumes、dns、dns_search、backend_options、privileged等。
Skip Commits（跳过提交）
Woodpecker 允许通过在提交信息中添加[SKIP CI]或[CI SKIP]来跳过单个提交，该匹配不区分大小写：
git commit -m "updated README [CI SKIP]"Steps（步骤）
Workflow 中的每一步都在指定的容器（container）内执行命令。步骤默认按顺序执行；如果需要并行，可以使用depends_on。与提交关联的代码会通过 git 检出到一个 workspace，该 workspace 会作为工作目录挂载到 workflow 的每一个步骤。
steps: - name: backend image: golang commands: + - go build + - go test文件变更在步骤间是累积的
- Woodpecker 在 workflow 开始时克隆源代码；
- 由于同一个 volume 被挂载到所有步骤，步骤之间对文件的修改会被持久保留。
steps: - name: build image: debian commands: - echo "test content" > myfile - name: a-test-step image: debian commands: - cat myfile上面的例子中，build步骤写入的myfile可以在后续的a-test-step中被读取，这正是 CI 场景中"构建产物跨步骤共享"的基础机制。
image
Woodpecker 会拉取定义的镜像，并将其作为执行 workflow 步骤命令、插件（plugins）和服务容器（service containers）的运行环境。
当使用local后端时，image条目用于指定执行命令所使用的 shell（如 Bash 或 Fish）。
steps: - name: build + image: golang:1.6 commands: - go build - go test - name: prettier + image: woodpeckerci/plugin-prettier services: - name: database + image: mysqlWoodpecker 支持来自任何 Docker 镜像仓库的合法镜像：
image: golang image: golang:1.7 image: library/golang:1.7 image: index.docker.io/library/golang image: index.docker.io/library/golang:1.7关于从不同仓库使用镜像的更多内容，见 41-registries.md。
pull
默认情况下，Woodpecker不会自动升级容器镜像，仅在镜像尚未存在时才进行拉取。如需在有更新时总是拉取最新镜像，使用pull选项：
steps: - name: build image: golang:latest + pull: true在源码中Pull是Container上的布尔字段（container.go），pull: true会指示对应后端在启动容器前强制执行镜像拉取策略。
commands
每个步骤的命令会串行执行，就像你在本地 shell 中逐条输入一样。
steps: - name: backend image: golang commands: + - go build + - go test这里没有任何魔法。上述命令会被转换成一个简单的 shell 脚本，大致如下：
#!/bin/sh set -e go build go test该脚本随后作为容器的 entrypoint 被执行。下面的 docker 命令是执行方式的一个（不完整的）示例：
docker run --entrypoint=build.sh golang[!NOTE] 只有**构建步骤（build steps）**可以定义
commands。插件（plugins）和服务（services）不能使用 commands。
entrypoint
允许你为容器指定 entrypoint。注意它必须是命令及其参数的列表（例如["/bin/sh", "-c"]）。
如果你定义了commands，默认 entrypoint 将是["/bin/sh", "-c", "echo $CI_SCRIPT | base64 -d | /bin/sh -e"]。你也可以在使用commands时，通过CI_SCRIPT（Base64 编码）配合自定义 shell。
environment
Woodpecker 支持向单个步骤传递环境变量。
更多细节见 environment 文档。源码层面，Environment是map[string]any类型的字段（container.go），既可以写为键值映射，也可以与内置CI_变量一起注入步骤。
failure
某些步骤允许失败而不导致整个 workflow（进而 pipeline）报告失败——例如执行 lint 检查的步骤。为此，给步骤添加failure: ignore。如果 Woodpecker 在执行该步骤时遇到错误，它会将该步骤标记为失败，但仍会继续执行后续步骤（如果有），且不影响 workflow 的状态。
steps: - name: backend image: golang commands: - go build - go test + failure: ignore如果希望在步骤失败时取消整个 pipeline，可以设置failure: cancel；默认行为是failure: fail（失败即中断）。
when- 条件执行
Woodpecker 支持通过when块为步骤定义一组条件。只要when块中至少一个条件求值为 true，步骤就会执行，否则被跳过。单个条件只有在其所有子条件都为 true 时才为 true。一个条件可以是类似这样的检查：
steps: - name: prettier image: woodpeckerci/plugin-prettier + when: + - event: pull_request + repo: test/test + - event: push + branch: main上面的prettier步骤在满足以下任一条件时执行：
- pipeline 由仓库
test/test的 pull request 触发； - pipeline 由对
main分支的 push 触发。
这个"列表内 OR、单个条件内 AND"的语义在源码中有直接体现：When.Match遍历所有约束（Constraints），只要其中一个Constraint.Match返回 true 即整体为 true（见 constraint.go）。when同时支持列表与映射两种 YAML 写法——映射形式会被包装成单元素约束列表（UnmarshalYAML中yaml.MappingNode分支）。
repo
按仓库执行条件示例：
steps: - name: prettier image: woodpeckerci/plugin-prettier + when: + - repo: test/testbranch
[!NOTE] 分支条件不适用于 tag。
按分支执行条件示例：
steps: - name: prettier image: woodpeckerci/plugin-prettier + when: + - branch: main此时步骤会在 main 分支触发，但也会在 pull request 的目标分支为
main时触发。如需进一步限制为仅 main 分支的 push，请添加事件条件。
当分支为main或develop时执行步骤：
when: - branch: [main, develop]当分支以prefix/*开头时执行步骤：
when: - branch: prefix/*分支匹配使用 doublestar 实现，注意：以*开头的模式应加引号，字面/需要转义。几个示例：
*\\/*匹配恰好包含 1 个/的模式；*\\/**匹配至少包含 1 个/的模式；*匹配不包含/的模式；**匹配一切。
使用自定义 include/exclude 逻辑执行步骤：
when: - branch: include: [main, release/*] exclude: [release/1.0.0, release/1.1.*]底层实现中，branch、repo、ref、instance等都复用constraint.List类型（list.go），它支持include+exclude两种模式，匹配均通过doublestar.Match完成；List.Match的规则是：命中 exclude 返回 false，命中 include 返回 true，未设置 include 时默认 true。此外源码确认了文档中的行为——branch条件在m.Curr.Event == metadata.EventTag时不会被匹配（见 constraint.go 的Match方法）。
event
可用事件包括：
push：向分支推送提交时触发；pull_request：打开 pull request 或向其推送新提交时触发；pull_request_closed：pull request 被关闭或合并时触发；pull_request_metadata：pull request 元数据发生变化时触发（如标题、正文、标签、里程碑等）；tag：推送 tag 时触发；release：创建 release、预发布或草稿时触发（可通过 evaluate 结合 环境变量 进一步过滤）；deployment：在仓库中创建 deployment 时触发（该事件可直接从 Woodpecker 触发，GitHub 也支持 webhook 触发）；cron：cron 任务执行时触发；manual：用户手动触发 pipeline 时触发。
构建事件为tag时执行步骤：
when: - event: tagpipeline 事件为对指定分支的push时执行步骤：
when: - event: push + branch: main多个事件执行步骤：
when: - event: [push, tag, deployment]cron
该过滤器仅适用于 cron 事件，并按 cron 任务的名称过滤。同时请务必在when过滤器中也加上event: cron条件。
when: - event: cron cron: sync_* # name of your cron jobcron 的更多内容见 45-cron.md。源码中cron过滤仅在m.Curr.Event == metadata.EventCron时参与匹配（constraint.go）。
ref
ref过滤器比较 workflow 所针对的 git 引用（ref）。例如，它可以过滤必须以v开头的 tag：
when: - event: tag ref: refs/tags/v*status
默认情况下，步骤只在 workflow 运行到该点之前一直成功时才执行，这等价于status: [ success ]。
status过滤器允许你覆盖这一行为。唯一接受的值是success和failure。
一个常见场景是在失败时执行步骤，例如为失败的 workflow/pipeline 发送通知。若希望无论结果如何都运行步骤，可同时列出两个值：
steps: - name: notify image: alpine + when: + - status: [ success, failure ]该过滤器对其他过滤器是"感知"的。如果你希望在事件为tag的失败时运行，而事件为pull_request时无论成败都运行：
when: + - event: tag + status: [ failure ] + - event: pull_request + status: [ success, failure ]如果没有匹配的过滤器，或所有匹配的过滤器都未设置status，则使用默认行为——仅在成功时运行。上面的例子中，当事件既不是tag也不是pull_request时就会发生这种情况。
源码中对status的语义做了精细处理：IncludesStatusFailure要求某条匹配的约束显式包含failure；而IncludesStatusSuccess则假定 success 被隐式包含，除非约束明确列出且不含success（见 constraint.go）。
platform
[!NOTE] 该条件应与 matrix（矩阵） workflow 配合使用，因为常规 workflow 只会被单个 agent 执行，而该 agent 只有一种架构。
为特定平台执行步骤：
when: - platform: linux/amd64使用通配符为特定平台执行步骤：
when: - platform: [linux/*, windows/amd64]matrix
为单个矩阵组合执行步骤：
when: - matrix: GO_VERSION: 1.5 REDIS_VERSION: 2.8源码中matrix过滤只在步骤级（global=false）参与匹配，用于将矩阵变量与当前执行的矩阵组合比对（constraint.go 的Constraint.Match）。
instance
仅在指定主机名的某个 Woodpecker 实例上执行步骤：
when: - instance: stage.woodpecker.company.compath
[!INFO] 路径条件仅应用于push和pull_request事件。
仅当 pipeline 修改了某些文件时执行步骤：
when: - path: 'src/*'你可以使用 glob 模式 匹配变更文件，并通过include指定命中即执行、exclude指定未变更才执行。对于没有文件变更的 pipeline（空提交，或tag等无文件变更的事件），可用on_empty设置该条件在这些情况下应为true（默认）还是false。
when: - path: include: ['.woodpecker/*.yaml', '*.ini'] exclude: ['*.md', 'docs/**'] ignore_message: '[ALL]' on_empty: true[!INFO] 在提交信息中传入类似
[ALL]的定义 ignore-message，会忽略所有路径条件以及on_empty设置。
Path类型的完整字段（include、exclude、ignore_message、on_empty）定义在 path.go，其匹配逻辑依次为：提交信息包含ignore_message（大小写不敏感）直接返回 true → 无变更文件时返回on_empty的取值 → 命中 exclude 返回 false → 未命中 include 返回 false。注意Match方法仅当事件是 pull 事件或 push 事件时才被调用（constraint.go），这与文档"仅适用于 push/pull_request"的说明一致。
evaluate
仅当提供的 evaluate 表达式求值为 true 时执行步骤。表达式中可以使用内置的CI_变量和自定义变量。
表达式语法见底层库 expr-lang 的语言定义文档。
在仓库owner/repo的默认分支上进行 push 时运行：
when: - evaluate: 'CI_PIPELINE_EVENT == "push" && CI_REPO == "owner/repo" && CI_COMMIT_BRANCH == CI_REPO_DEFAULT_BRANCH'在用户woodpecker-ci创建的提交上运行：
when: - evaluate: 'CI_COMMIT_AUTHOR == "woodpecker-ci"'跳过所有提交信息中包含please ignore me的提交：
when: - evaluate: 'not (CI_COMMIT_MESSAGE contains "please ignore me")'在带有deploy标签的 pull request 上运行：
when: - evaluate: 'CI_COMMIT_PULL_REQUEST_LABELS contains "deploy"'仅在SKIP=true时跳过步骤，否则（或未定义时）运行：
when: - evaluate: 'SKIP != "true"'源码实现中，evaluate表达式通过expr.Compile(c.Evaluate, expr.Env(env), expr.AllowUndefinedVariables(), expr.AsBool())编译并求值（constraint.go），AllowUndefinedVariables()意味着未定义的变量不会导致编译失败——这正是SKIP != "true"在SKIP未定义时仍可工作的原因。
depends_on
正常情况下，workflow 中的步骤按照定义顺序串行执行。一旦为某个步骤设置了depends_on，就会启用有向无环图（DAG）调度：除设置了依赖关系的步骤外，workflow 中的所有步骤都会并行执行：
steps: - name: build # build 立即执行 image: golang commands: - go build - name: deploy image: woodpeckerci/plugin-s3 settings: bucket: my-bucket-name source: some-file-name target: /target/some-file + depends_on: [build, test] # deploy 在 build 和 test 完成后执行 - name: test # 未设置依赖，立即执行 image: golang commands: - go test[!NOTE] 可以通过添加空数组
depends_on: []定义一个无依赖、立即开始的步骤。为单个步骤设置depends_on后，如果其他步骤未指定进一步依赖，它们也会被立即执行。
steps: - name: check code format image: mstruebing/editorconfig-checker depends_on: [] # 启用并行步骤 ...底层调度在 dag.go 中实现：只要任一步骤的depends_on非 nil（即 YAML 中出现过该字段），isDAG()返回 true，整个 workflow 改用compileByDependsOn()构建阶段；否则退回compileSequence()纯串行模式。DAG 编译还会做三类校验：重名步骤报ErrStepDuplicateName、缺失的必需依赖报ErrStepMissingDependency、依赖成环报ErrStepDependencyCycle（通过 DFS 检测）。同一层内无依赖的步骤会按原始配置位置排序，保证多次运行顺序稳定。
volumes
Woodpecker 允许在 YAML 中定义 Docker 卷。你可以用该参数将宿主机的文件或文件夹挂载进容器。
更多细节见 volumes 文档。
detach
Woodpecker 允许将步骤分离（detach），使其在后台运行直到 workflow 结束。
更多细节见 services 文档中的 detachment 小节。
directory
使用directory，可以设置仓库的子目录或 Docker 容器内的绝对路径，命令将在此目录中运行。
backend_options
通过backend_options可以定义针对具体后端（backend）的选项。例如，可以指定 Docker 容器中使用的用户和/或组，或指定 Kubernetes 的 service account。
更多细节见所用后端的文档：
- Docker 后端
- Kubernetes 后端
services
Woodpecker 可以提供服务容器（service containers），例如在 workflow 执行期间运行数据库或缓存容器。
更多细节见 services 文档。
workspace
workspace 定义了所有 workflow 步骤共享的卷和工作目录。默认的 workspace 基路径是/woodpecker，路径会附加仓库 URL（src/{url-without-schema}）。例如：/woodpecker/src/github.com/octocat/hello-world。
可以通过 YAML 中的 workspace 块自定义：
+workspace: + base: /go + path: src/github.com/octocat/hello-world steps: - name: build image: golang:latest commands: - go get - go test[!NOTE] 插件（plugins）的 workspace 基路径始终为
/woodpecker。
base属性定义所有步骤共享的基础卷。这确保你的源代码、依赖和编译产物能在步骤之间持久保存与共享：
workspace: + base: /go path: src/github.com/octocat/hello-world steps: - name: deps image: golang:latest commands: - go get - go test - name: build image: node:latest commands: - go build这等价于下面的 docker 命令：
docker volume create my-named-volume docker run --volume=my-named-volume:/go golang:latest docker run --volume=my-named-volume:/go node:latestpath属性定义构建的工作目录，代码会被克隆到这里，它也是构建过程中每个步骤的默认工作目录。path必须是相对路径，并与base路径组合：
workspace: base: /go + path: src/github.com/octocat/hello-worldgit clone https://github.com/octocat/hello-world \ /go/src/github.com/octocat/hello-world在 workflow.go 中，Workspace结构体仅含Base与Path两个字段；默认值（/woodpecker基路径、src/{url}组合方式）由编译阶段注入，最终会转换成对应后端（Docker/Kubernetes/local 等）的卷与工作目录配置。
matrix
Woodpecker 内置了对矩阵构建（matrix builds）的支持。Woodpecker 会为矩阵中的每种组合分别执行一个构建任务，使你能够用多个配置构建和测试同一次提交。
更多细节见 matrix 构建文档。
labels
你可以为 workflow 定义标签，以便选择执行该 workflow 的 agent。一个 agent 只有在每一个分配给它的标签都与该 agent 的标签匹配时，才会接手并执行该 workflow。
要指定额外的 agent 标签，见 Agent 配置选项。agent 至少有四个默认标签：platform=agent-os/agent-arch、hostname=my-agent、backend=docker（agent 后端的类型）和repo=*。agent 可以使用*作为标签的通配符，例如repo=*匹配任意仓库。
值为空的 workflow 标签会被忽略。默认情况下，每个 workflow 至少带有repo=your-user/your-repo-name标签；如果为 workflow 设置了 platform 属性，它还会带有类似platform=your-os/your-arch的标签。
[!WARNING] 带有
woodpecker-ci.org前缀的标签由 Woodpecker 管理，不能在 pipeline 定义中设置。
可以以键值映射的形式添加额外标签：
+labels: + location: europe # 只有 `location=europe` 或 `location=*` 的 agent 会被使用 + weather: sun + hostname: "" # 空标签会被忽略 steps: - name: build image: golang commands: - go build - go test按平台过滤
要将 workflow 配置为仅在具有特定平台的 agent 上执行，可以使用platform键。可用平台参见官方 go 文档。平台语法为GOOS/GOARCH形式，如linux/arm64或linux/amd64。
示例：假设有两个 agent，一个linux/arm，一个linux/amd64。之前该 workflow 可能会在任意 agent上执行（Woodpecker 对在哪里运行并不挑剔）。通过如下设置，它只会在平台为linux/arm64的 agent 上执行：
+labels: + platform: linux/arm64 steps: - name: build image: golang commands: - go build - go testvariables
Woodpecker 支持使用 YAML 锚点与别名 作为 workflow 配置中的变量。
更多细节与示例见 Advanced usage 文档。
clone
如果没有显式定义 clone 步骤，Woodpecker 会自动配置一个默认的 clone 步骤。如果使用local后端，默认 clone 步骤正常工作要求 plugin-git 二进制位于你的$PATH中；否则，你仍可以手写一个 clone 步骤。
你可以手动配置 workflow 中的 clone 步骤以自定义它：
+clone: + git: + image: woodpeckerci/plugin-git steps: - name: build image: golang commands: - go build - go test覆盖深度的配置示例：
clone: - name: git image: woodpeckerci/plugin-git + settings: + partial: false + depth: 50使用自定义 clone 插件的配置示例：
clone: - name: git + image: octocat/custom-git-pluginGit Submodules（子模块）
若要使用克隆仓库所用的凭据来克隆其子模块，请将.gitmodules中的 url 从git改为https：
[submodule "my-module"] path = my-module -url = git@github.com:octocat/my-module.git +url = https://github.com/octocat/my-module.git如果希望使用 ssh 克隆的用户在.gitmodules中保留 ssh url，而 Woodpecker 使用 https url，可以添加submodule_override：
clone: - name: git image: woodpeckerci/plugin-git settings: recursive: true + submodule_override: + my-module: https://github.com/octocat/my-module.git steps: ...skip_clone
[!WARNING] 默认 clone 步骤以
root身份执行，以确保 workspace 目录可被任何用户访问（权限0777）。这是为了让 rootless 步骤容器能够写入 workspace 目录。如果 rootless 步骤容器配合skip_clone使用，用户必须确保提供一个无特权容器可访问的合适 workspace 目录，例如/tmp。
默认情况下 Woodpecker 会自动添加 clone 步骤，可通过 clone 属性配置。如果完全不需要 clone 步骤，可以用下面的方式跳过：
skip_clone: true在 workflow.go 中SkipClone是Workflow结构体的布尔字段；编译器在配置默认 clone 步骤时会检查该开关（见 compiler.go 中的defaultCloneName常量与相关逻辑）。
when- 全局 workflow 条件
Woodpecker 允许基于某些条件跳过整个 workflow（而不只是步骤）。只有当when块中的所有条件都求值为 true 时，workflow 才会执行，否则它不会包含在 pipeline 中。其他通过depends_on引用了被跳过 workflow 的 workflow 也会被排除。若希望在被引用的 workflow 不在 pipeline 中时忽略该依赖，请在依赖上使用optional: true。
关于各过滤器的更多信息，参见步骤级when过滤器。
按分支执行条件示例：
+when: + branch: main + steps: - name: prettier image: woodpeckerci/plugin-prettier此时 workflow 在main上触发，但也会在 pull request 的目标分支为main时触发。
depends_on（workflow 级）
Woodpecker 支持为一个仓库定义多个 workflow，这些 workflow 相互独立运行。若要让它们互相依赖，可以使用depends_on关键字。
depends_on中的可选依赖
depends_on的每个条目可以是字符串（必需依赖），也可以是带有name和optional: true的对象。当被引用的 workflow 或步骤不在 pipeline 中时（例如被when条件过滤掉），可选依赖会被静默忽略；如果存在，workflow 会照常等待它们。详见可选依赖。
depends_on: - check-a - name: check-b optional: true该语法由 depends_on.go 中的DependsOn类型实现：UnmarshalYAML同时接受纯字符串、字符串数组、对象数组及混合数组四种形式；OptionalNames()与RequiredNames()区分两类依赖，而编译期（dag.go 的convertDAGToStages）会为被过滤掉的依赖做解析——可选依赖被静默丢弃，必需依赖缺失则报ErrStepMissingDependency。
步骤的高级网络选项
[!WARNING] 仅在仓库设置中由管理员开启 'Trusted Network'（可信网络）选项后才允许使用。
dns
如果后端引擎支持修改 DNS 服务器和查找域，该选项可用于为特定步骤将默认 DNS 配置改为自定义配置。
steps: - name: build image: plugin/abc dns: 1.2.3.4 dns_search: 'internal.company'特权模式（Privileged mode）
Woodpecker 允许在 YAML 中配置特权模式。你可以用该参数以提升的能力（escalated capabilities）启动容器。
[!INFO] 特权模式仅对受信任的仓库（trusted repositories）开放，出于安全考虑应仅在私有环境中使用。参见项目设置启用 trusted 模式。
steps: - name: build image: docker environment: - DOCKER_HOST=tcp://docker:2375 commands: - docker --tls=false ps services: - name: docker image: docker:dind commands: dockerd-entrypoint.sh --storage-driver=vfs --tls=false + privileged: true在 container.go 中Privileged被标注为 "Docker and Kubernetes Specific"（Docker 与 Kubernetes 专用）字段，最终由对应后端将其转换为容器运行时权限配置。
配置校验与常见误区
Woodpecker 仓库内置了一套完整的配置 schema 校验器，位于 schema.json。它定义了配置文件的顶层结构（steps为必填项，其余如when、workspace、clone、services、matrix、labels、depends_on、concurrency、skip_clone均为可选），并给出了depends_on条目（字符串或{name, optional}对象）、concurrency（整数或对象）等类型的合法形态。编写配置时注意以下几点可避免大部分报错：
- 步骤必须声明
image，commands仅限构建步骤使用，插件与服务容器不能使用； status只接受success与failure，且默认成功时才运行；branch不作用于 tag 事件，tag 过滤请使用ref；path仅对 push 与 pull_request 事件生效，空提交时由on_empty决定；cron过滤需要同时声明event: cron；- 为步骤设置
depends_on会触发整个 workflow 进入 DAG 并行模式，重名步骤、依赖缺失与循环依赖都会被编译器拒绝； - 带
woodpecker-ci.org前缀的标签不可自定义。
小结
本文从 Workflow 定义出发，完整梳理了 Woodpecker 步骤语法（image、pull、commands、entrypoint、failure、environment等）与顶层区块（services、workspace、matrix、labels、variables、clone、skip_clone），重点剖析了when条件执行的十类过滤器及其"列表 OR、单条 AND"的求值语义、depends_on从串行切换到 DAG 并行调度的机制，以及特权模式、高级网络选项等进阶能力。所有语法行为都能在 pipeline/frontend/yaml 的源码（类型定义、约束匹配、DAG 编译、schema 校验）中找到对应实现。掌握这些语法之后，你可以编写出既有精细条件控制、又能最大化并行效率的 Woodpecker pipeline 配置。
- CI/CD
- DevOps
【免费下载链接】woodpecker
Woodpecker is a simple, yet powerful CI/CD engine with great extensibility.
相关推荐
Woodpecker Workflow 语法完全指南：从 steps 定义到条件执行与并行编排
Woodpecker Workflow 语法完全指南：从 steps 定义到条件执行与并行编排 本篇技术指南以 Woodpecker CI/CD 引擎的 Wor
CI/CDDevOpsWoodpecker 工作流语法完全指南：从 steps 定义到条件执行与 DAG 编排
Woodpecker 工作流语法完全指南：从 steps 定义到条件执行与 DAG 编排 Woodpecker 使用一个位于仓库根目录（默认 .woodpeck
CI/CDDevOpsWoodpecker Workflow 语法完全指南：从步骤定义到条件执行与并行调度
Woodpecker Workflow 语法完全指南：从步骤定义到条件执行与并行调度 导读 本文是 Woodpecker CI/CD 引擎中 Workflow
CI/CDDevOps
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
