尧图网站建设 
CI/CDDevOps【免费下载链接】woodpeckerWoodpecker is a simple, yet powerful CI/CD engine with great extensibility.项目地址https://gitcode.com/gh_mirrors/wo/woodpecker点击查看免费下载本篇技术指南以 Woodpecker 官方文档《Creating plugins》为骨架系统讲解如何将一个自定义逻辑打包为 Docker 镜像并接入 Woodpecker 流水线你将掌握settings:参数到PLUGIN_*环境变量的完整转换规则含复杂类型 JSON 序列化与from_secret秘密注入、插件元数据的编写方式以及从零构建、本地验证到发布一个 webhook 插件的全流程并附带仓库源码级实现佐证。插件是什么插件Plugin本质上就是一个以插件逻辑作为ENTRYPOINT的 Docker 容器。在流水线中插件被配置为一个 step步骤用于执行预先定义好的任务例如部署代码、发布制品、发送通知等。与普通命令步骤不同插件应当只暴露插件作者设计好的功能入口而不是任意代码执行能力。关于插件的使用方式、隔离限制与官方插件索引可参考 Plugins 总览。本节聚焦「如何编写一个插件」。Settings插件的配置协议为了让用户能够配置插件行为插件应使用settings:字段。Woodpecker 会把这些设置以环境变量的形式注入插件容器环境变量统一使用大写命名并带有PLUGIN_前缀例如设置项url会变成环境变量PLUGIN_URL字符-以及.会被转换为下划线_例如some_String得到PLUGIN_SOME_STRINGCamelCase 不会被保留anInt得到的是PLUGIN_ANINT而不是PLUGIN_AN_INT。这一规则在源码中对应pipeline/frontend/yaml/compiler/settings/params.go的sanitizeParamKey函数params.go它先将.和-全部替换为_再执行strings.ToUpper。同名测试用例params_test.go验证了dry-run、dry_Run、dry.run三种写法都会归一化为PLUGIN_DRY_RUN而upperfalse时则保留原大小写PLUGIN_dry-run。在流水线编译阶段convert.go 分别对container.Settings与container.Environment调用ParamsToEnv前者使用前缀PLUGIN_并转大写后者不添加前缀且保持原样——这正是「settings 注入到插件、environment 注入到普通步骤」两种通道的底层差异。基础 Settings标量类型一律转字符串任何基础 YAML 标量类型都会被转换为字符串后注入设置项环境变量值some-bool: falsePLUGIN_SOME_BOOLfalsesome_String: helloPLUGIN_SOME_STRINGhelloanInt: 3PLUGIN_ANINT3源码层面sanitizeParamValueparams.go对布尔值使用strconv.FormatBool对整数与浮点数使用fmt.Sprintf格式化最终全部以字符串形式写入环境变量。复杂 Settings自动 JSON 序列化除了标量settings:还支持映射map与列表list等复杂结构它们会被序列化为 JSON 字符串后传给插件steps: - name: plugin image: foo/plugin settings: complex: abc: 2 list: - 2 - 3以上配置最终注入的环境变量PLUGIN_COMPLEX的值为{abc: 2, list: [ 2, 3 ]}。这一过程由handleComplexparams.go实现先将值通过 YAML 库yaml.Marshal序列化再调用yaml2json.Convert转换为 JSON 字符串。测试用例params_test.go给出了更多可参考的转换结果列表slice: [1, 2, 3]→PLUGIN_SLICE1,2,3纯标量列表会被逗号连接而非 JSON简单映射map: {hello: world}→PLUGIN_MAP{hello:world}结构体列表 →PLUGIN_COMPLEX[{name:Jack},{name:Jill}]点号键名from.address→PLUGIN_FROM_ADDRESSnoreplyexample.com列表中出现nil等空条目时会保留空位如PLUGIN_Aa,且复杂类型嵌套nil不会导致 panic对应 params_test.go 中的边界用例。秘密值Secrets通过 from_secret 注入敏感信息不应硬编码在 YAML 中插件设置应通过from_secret引用 Woodpecker 的秘密存储。用法如下steps: - name: plugin image: foo/plugin settings: TOKEN: from_secret: secret_tokenWoodpecker 的秘密按仓库、组织、全局三级划分后者优先级最高具体管理与使用语法见 Secrets 指南。源码中injectSecretparams.go会探测设置值是否为from_secret请求若命中则通过回调从秘密存储取值并注入环境变量如上例即PLUGIN_TOKEN若秘密不存在或不允许使用则直接报错终止编译。值得注意的是injectSecretRecursiveparams.go会递归遍历复杂结构因此嵌套在 map 或 list 内部的from_secret同样会被解析——例如在list.map的密码字段中使用from_secret: cb_password最终 JSON 中会替换为真实秘密值见 params_test.go。同时ParamsToEnv会通过secretMapping记录哪些环境变量包含秘密值从代码结构看该映射用于后续对日志中的敏感内容做脱敏处理。插件库Plugin Library如果使用 Go 编写插件Woodpecker 官方提供了插件库可以方便地读取内置环境变量和你的 settings 配置免去手写环境变量解析代码。官方插件库位于 woodpecker-plugins 组织的go-plugin仓库codeberg.org/woodpecker-plugins/go-plugin其中同时提供了插件元数据读取与常用工具函数。插件元数据Metadata你可以在插件文档docs.md中使用 Markdown 头front-matter定义插件元数据这些数据会被 Woodpecker 的插件索引收录展示。支持的元数据字段如下name插件的完整名称唯一必填字段icon插件图标的 URLdescription一段简短的功能描述author作者姓名tags关键词列表例如 clone 插件可用[git, clone]containerImage容器镜像名称containerImageUrl容器镜像的链接url插件的主页或源码仓库地址。如果你希望插件被收录进索引应尽可能填写全部字段但只有name是必需的。实战从零构建一个 Webhook 插件下面以「在流水线中发起 HTTP 请求」的 webhook 插件为例走一遍完整的创建流程。该插件仅使用简单的 shell 脚本即可完成。用户视角的配置插件作者交付后用户在流水线中这样使用steps: - name: webhook image: foo/webhook settings: url: https://example.com method: post body: | hello world根据前面的规则这三个设置分别注入为PLUGIN_URL、PLUGIN_METHOD与PLUGIN_BODY。编写插件逻辑创建 shell 脚本script.sh通过 curl 发起请求。YAML 配置参数已作为大写、带PLUGIN_前缀的环境变量传入#!/bin/sh curl \ -X ${PLUGIN_METHOD} \ -d ${PLUGIN_BODY} \ ${PLUGIN_URL}打包为镜像创建Dockerfile把脚本加入镜像并将其设置为容器的ENTRYPOINT# please pin the version, e.g. alpine:3.19 FROM alpine ADD script.sh /bin/ RUN chmod x /bin/script.sh RUN apk -Uuv add curl ca-certificates ENTRYPOINT /bin/script.sh注意官方建议锁定基础镜像版本例如alpine:3.19以保证可复现性。构建并推送到 Docker Registry 后插件即可分享给社区使用docker build -t foo/webhook . docker push foo/webhook本地验证在提交到仓库之前可以直接用docker run模拟 Woodpecker 的注入行为本地验证插件是否工作正常docker run --rm \ -e PLUGIN_METHODpost \ -e PLUGIN_URLhttps://example.com \ -e PLUGIN_BODYhello world \ foo/webhook这与 Woodpecker 运行时注入环境变量的方式完全一致编译器先把settings转成PLUGIN_*环境变量convert.go再由各后端Docker、Kubernetes、local 等注入容器。插件最佳实践多架构构建为不同架构构建插件镜像让更多用户能够使用。至少应支持amd64与arm64。为 local 后端提供二进制使用 Woodpecker 的local后端无需 Docker、直接在宿主机运行步骤的用户需要直接执行的二进制文件这些二进制也应针对不同的 OS/架构构建。优先使用内置环境变量尽量利用 Woodpecker 注入的内置变量如CI_COMMIT_SHA、CI_COMMIT_TAG、CI_PIPELINE_NUMBER等而不是硬编码信息完整清单见 内置环境变量。只依赖 settings 与内置变量不要要求用户额外配置environment见 环境变量文档也不要要求特定的秘密名称——所有配置都应通过settings:统一暴露。编写 docs.md为插件添加docs.md文件列出全部设置项与插件元数据参考官方 git 插件的docs.md写法。提交插件索引使用你的docs.md将插件提交到官方插件索引方便社区发现和使用示例可参考索引中git-clone插件的页面。与流水线机制的衔接最后补充两点插件在 Woodpecker 内部的运行约束详见 Plugins 总览它们直接影响插件作者的设计决策插件与普通步骤共享构建工作区挂载于/woodpecker因此可以访问源码树插件不能与commands或entrypoint同时使用会失败若在插件步骤上使用environment则该容器内部将不再按插件处理无法通过插件过滤器访问秘密也不会被隐式提权。理解这些机制配合本篇的 settings 转换规则与实战示例即可快速产出符合生态规范、可被广泛复用的 Woodpecker 插件。赞分享CI/CDDevOps【免费下载链接】woodpeckerWoodpecker is a simple, yet powerful CI/CD engine with great extensibility.项目地址https://gitcode.com/gh_mirrors/wo/woodpecker点击查看免费下载相关推荐Woodpecker 插件开发实战构建可配置的 CI/CD 插件Settings、Secrets 与最佳实践Woodpecker 插件开发实战构建可配置的 CI/CD 插件Settings、Secrets 与最佳实践 本篇指南以 Woodpecker CI/CDCI/CDDevOpsMbed TLS 示例程序完全指南从 AES 文件加密到 TLS 客户端/服务端实战Mbed TLS 示例程序完全指南从 AES 文件加密到 TLS 客户端/服务端实战 lib/mbedtls/programs/README.md 是 MbeCI/CDDevOpsCELLxGENE单细胞转录组学数据探索的架构革命与科学工作流重塑CELLxGENE单细胞转录组学数据探索的架构革命与科学工作流重塑 在单细胞转录组学研究的复杂数据生态中研究者长期面临高维数据可视化与交互探索的技术瓶颈。传上一篇Android Database SQLCipher 常见问题解决方案下一篇Android Hidden API 实战教程从零开始构建自定义系统工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Woodpecker CI 插件开发指南：Settings 参数传递、元数据与发布实战
CI/CDDevOps【免费下载链接】woodpeckerWoodpecker is a simple, yet powerful CI/CD engine with great extensibility.项目地址https://gitcode.com/gh_mirrors/wo/woodpecker点击查看免费下载本篇技术指南以 Woodpecker 官方文档《Creating plugins》为骨架系统讲解如何将一个自定义逻辑打包为 Docker 镜像并接入 Woodpecker 流水线你将掌握settings:参数到PLUGIN_*环境变量的完整转换规则含复杂类型 JSON 序列化与from_secret秘密注入、插件元数据的编写方式以及从零构建、本地验证到发布一个 webhook 插件的全流程并附带仓库源码级实现佐证。插件是什么插件Plugin本质上就是一个以插件逻辑作为ENTRYPOINT的 Docker 容器。在流水线中插件被配置为一个 step步骤用于执行预先定义好的任务例如部署代码、发布制品、发送通知等。与普通命令步骤不同插件应当只暴露插件作者设计好的功能入口而不是任意代码执行能力。关于插件的使用方式、隔离限制与官方插件索引可参考 Plugins 总览。本节聚焦「如何编写一个插件」。Settings插件的配置协议为了让用户能够配置插件行为插件应使用settings:字段。Woodpecker 会把这些设置以环境变量的形式注入插件容器环境变量统一使用大写命名并带有PLUGIN_前缀例如设置项url会变成环境变量PLUGIN_URL字符-以及.会被转换为下划线_例如some_String得到PLUGIN_SOME_STRINGCamelCase 不会被保留anInt得到的是PLUGIN_ANINT而不是PLUGIN_AN_INT。这一规则在源码中对应pipeline/frontend/yaml/compiler/settings/params.go的sanitizeParamKey函数params.go它先将.和-全部替换为_再执行strings.ToUpper。同名测试用例params_test.go验证了dry-run、dry_Run、dry.run三种写法都会归一化为PLUGIN_DRY_RUN而upperfalse时则保留原大小写PLUGIN_dry-run。在流水线编译阶段convert.go 分别对container.Settings与container.Environment调用ParamsToEnv前者使用前缀PLUGIN_并转大写后者不添加前缀且保持原样——这正是「settings 注入到插件、environment 注入到普通步骤」两种通道的底层差异。基础 Settings标量类型一律转字符串任何基础 YAML 标量类型都会被转换为字符串后注入设置项环境变量值some-bool: falsePLUGIN_SOME_BOOLfalsesome_String: helloPLUGIN_SOME_STRINGhelloanInt: 3PLUGIN_ANINT3源码层面sanitizeParamValueparams.go对布尔值使用strconv.FormatBool对整数与浮点数使用fmt.Sprintf格式化最终全部以字符串形式写入环境变量。复杂 Settings自动 JSON 序列化除了标量settings:还支持映射map与列表list等复杂结构它们会被序列化为 JSON 字符串后传给插件steps: - name: plugin image: foo/plugin settings: complex: abc: 2 list: - 2 - 3以上配置最终注入的环境变量PLUGIN_COMPLEX的值为{abc: 2, list: [ 2, 3 ]}。这一过程由handleComplexparams.go实现先将值通过 YAML 库yaml.Marshal序列化再调用yaml2json.Convert转换为 JSON 字符串。测试用例params_test.go给出了更多可参考的转换结果列表slice: [1, 2, 3]→PLUGIN_SLICE1,2,3纯标量列表会被逗号连接而非 JSON简单映射map: {hello: world}→PLUGIN_MAP{hello:world}结构体列表 →PLUGIN_COMPLEX[{name:Jack},{name:Jill}]点号键名from.address→PLUGIN_FROM_ADDRESSnoreplyexample.com列表中出现nil等空条目时会保留空位如PLUGIN_Aa,且复杂类型嵌套nil不会导致 panic对应 params_test.go 中的边界用例。秘密值Secrets通过 from_secret 注入敏感信息不应硬编码在 YAML 中插件设置应通过from_secret引用 Woodpecker 的秘密存储。用法如下steps: - name: plugin image: foo/plugin settings: TOKEN: from_secret: secret_tokenWoodpecker 的秘密按仓库、组织、全局三级划分后者优先级最高具体管理与使用语法见 Secrets 指南。源码中injectSecretparams.go会探测设置值是否为from_secret请求若命中则通过回调从秘密存储取值并注入环境变量如上例即PLUGIN_TOKEN若秘密不存在或不允许使用则直接报错终止编译。值得注意的是injectSecretRecursiveparams.go会递归遍历复杂结构因此嵌套在 map 或 list 内部的from_secret同样会被解析——例如在list.map的密码字段中使用from_secret: cb_password最终 JSON 中会替换为真实秘密值见 params_test.go。同时ParamsToEnv会通过secretMapping记录哪些环境变量包含秘密值从代码结构看该映射用于后续对日志中的敏感内容做脱敏处理。插件库Plugin Library如果使用 Go 编写插件Woodpecker 官方提供了插件库可以方便地读取内置环境变量和你的 settings 配置免去手写环境变量解析代码。官方插件库位于 woodpecker-plugins 组织的go-plugin仓库codeberg.org/woodpecker-plugins/go-plugin其中同时提供了插件元数据读取与常用工具函数。插件元数据Metadata你可以在插件文档docs.md中使用 Markdown 头front-matter定义插件元数据这些数据会被 Woodpecker 的插件索引收录展示。支持的元数据字段如下name插件的完整名称唯一必填字段icon插件图标的 URLdescription一段简短的功能描述author作者姓名tags关键词列表例如 clone 插件可用[git, clone]containerImage容器镜像名称containerImageUrl容器镜像的链接url插件的主页或源码仓库地址。如果你希望插件被收录进索引应尽可能填写全部字段但只有name是必需的。实战从零构建一个 Webhook 插件下面以「在流水线中发起 HTTP 请求」的 webhook 插件为例走一遍完整的创建流程。该插件仅使用简单的 shell 脚本即可完成。用户视角的配置插件作者交付后用户在流水线中这样使用steps: - name: webhook image: foo/webhook settings: url: https://example.com method: post body: | hello world根据前面的规则这三个设置分别注入为PLUGIN_URL、PLUGIN_METHOD与PLUGIN_BODY。编写插件逻辑创建 shell 脚本script.sh通过 curl 发起请求。YAML 配置参数已作为大写、带PLUGIN_前缀的环境变量传入#!/bin/sh curl \ -X ${PLUGIN_METHOD} \ -d ${PLUGIN_BODY} \ ${PLUGIN_URL}打包为镜像创建Dockerfile把脚本加入镜像并将其设置为容器的ENTRYPOINT# please pin the version, e.g. alpine:3.19 FROM alpine ADD script.sh /bin/ RUN chmod x /bin/script.sh RUN apk -Uuv add curl ca-certificates ENTRYPOINT /bin/script.sh注意官方建议锁定基础镜像版本例如alpine:3.19以保证可复现性。构建并推送到 Docker Registry 后插件即可分享给社区使用docker build -t foo/webhook . docker push foo/webhook本地验证在提交到仓库之前可以直接用docker run模拟 Woodpecker 的注入行为本地验证插件是否工作正常docker run --rm \ -e PLUGIN_METHODpost \ -e PLUGIN_URLhttps://example.com \ -e PLUGIN_BODYhello world \ foo/webhook这与 Woodpecker 运行时注入环境变量的方式完全一致编译器先把settings转成PLUGIN_*环境变量convert.go再由各后端Docker、Kubernetes、local 等注入容器。插件最佳实践多架构构建为不同架构构建插件镜像让更多用户能够使用。至少应支持amd64与arm64。为 local 后端提供二进制使用 Woodpecker 的local后端无需 Docker、直接在宿主机运行步骤的用户需要直接执行的二进制文件这些二进制也应针对不同的 OS/架构构建。优先使用内置环境变量尽量利用 Woodpecker 注入的内置变量如CI_COMMIT_SHA、CI_COMMIT_TAG、CI_PIPELINE_NUMBER等而不是硬编码信息完整清单见 内置环境变量。只依赖 settings 与内置变量不要要求用户额外配置environment见 环境变量文档也不要要求特定的秘密名称——所有配置都应通过settings:统一暴露。编写 docs.md为插件添加docs.md文件列出全部设置项与插件元数据参考官方 git 插件的docs.md写法。提交插件索引使用你的docs.md将插件提交到官方插件索引方便社区发现和使用示例可参考索引中git-clone插件的页面。与流水线机制的衔接最后补充两点插件在 Woodpecker 内部的运行约束详见 Plugins 总览它们直接影响插件作者的设计决策插件与普通步骤共享构建工作区挂载于/woodpecker因此可以访问源码树插件不能与commands或entrypoint同时使用会失败若在插件步骤上使用environment则该容器内部将不再按插件处理无法通过插件过滤器访问秘密也不会被隐式提权。理解这些机制配合本篇的 settings 转换规则与实战示例即可快速产出符合生态规范、可被广泛复用的 Woodpecker 插件。赞分享CI/CDDevOps【免费下载链接】woodpeckerWoodpecker is a simple, yet powerful CI/CD engine with great extensibility.项目地址https://gitcode.com/gh_mirrors/wo/woodpecker点击查看免费下载相关推荐Woodpecker 插件开发实战构建可配置的 CI/CD 插件Settings、Secrets 与最佳实践Woodpecker 插件开发实战构建可配置的 CI/CD 插件Settings、Secrets 与最佳实践 本篇指南以 Woodpecker CI/CDCI/CDDevOpsMbed TLS 示例程序完全指南从 AES 文件加密到 TLS 客户端/服务端实战Mbed TLS 示例程序完全指南从 AES 文件加密到 TLS 客户端/服务端实战 lib/mbedtls/programs/README.md 是 MbeCI/CDDevOpsCELLxGENE单细胞转录组学数据探索的架构革命与科学工作流重塑CELLxGENE单细胞转录组学数据探索的架构革命与科学工作流重塑 在单细胞转录组学研究的复杂数据生态中研究者长期面临高维数据可视化与交互探索的技术瓶颈。传上一篇Android Database SQLCipher 常见问题解决方案下一篇Android Hidden API 实战教程从零开始构建自定义系统工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考