尧图网页设计 
Dagger 项目贡献者开发指南用 Dagger 自身构建 Dagger 开发环境【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/dagger本文基于 Dagger 仓库根目录的 CONTRIBUTING.md系统讲解如何为 Dagger 贡献代码的完整流程从初始环境搭建安装 Dagger 稳定版、Changie、Fork 仓库到日常开发playground 联调、集成测试、Lint、本地文档服务再到 Pull Request 提交与评审的规范。读完本文你将能够复现 Dagger 维护者的自举式开发工作流——用 Dagger 来开发 Dagger掌握dagger api call engine-dev ...、dagger check ...等核心开发命令并理解这些命令背后对应的仓库源码engine-dev、test-split等开发模块。如何找到值得贡献的问题官方给出的最自然的贡献起点是先把自己的工作场景放到 Dagger 上跑一遍。你在真实使用中遇到的任何问题都可以成为贡献素材例如一个文档没有回答清楚的问题文档缺口一个工具链里的 bug一个缺失的功能或毛糙的边缘体验rough edge。选定问题后按自己的难度承受力挑选合适的条目着手。贡献过程中随时可以提问维护者明确表示乐于协助但有一条原则值得记住贡献体量越大越应该尽早与维护者沟通确认方向正确避免把精力花在最终不会被合并的方案上。如果计划向各语言 SDKTypeScript、Go、Python、Elixir、Java、PHP、Rust 等本身提贡献仓库中另有专门面向 SDK 的贡献说明 sdk/CONTRIBUTING.md应先阅读该文档。初始环境搭建1. 加入社区Dagger 官方将社区协作视为项目的核心特性之一强烈建议先加入其 Discord 服务器。持续的反馈和鼓励不仅能帮你节省大量排障时间也是保持长期贡献动机的关键。2. 安装 DaggerDogfooding开发 Dagger 所用的工具——不出所料——就是 Dagger 本身官方原话To develop Dagger, we use - surprise! - Dagger.。因此第一步是安装最新的稳定版发行如果你手上有旧版本务必先升级。安装脚本可直接参考仓库内的 install.sh。之所以必须使用稳定版而非本地开发版来启动开发是因为本地构建过程需要一个底座引擎来执行构建编排这个底座由--x-release机制固定到一个已知可用的构建见下文hack/build解析。3. 安装 ChangieChangie 是一个简单的 Release Note 管理工具。凡是涉及用户可感知变更user-facing changes的贡献都需要用它生成发布说明条目。请安装最新版 Changie后续在准备 PR 时使用changie new生成条目文件。仓库根目录 dagger.toml 中登记了 changelog 模块.dagger/modules/changelog且 engine-dev 模块的源码 在打包构建源时会专门排除!.changes目录——说明 changie 生成的.changes条目是仓库内被显式管理的一类文件。4. Git 配置在 GitHub 上找到dagger/dagger仓库并点击Fork克隆你的 forkgit clone gitgithub.com:$YOUR_GITHUB_USER/dagger.git添加上游仓库为新的 remotegit remote add upstream gitgithub.com:dagger/dagger.git贡献工作流官方把工作流概括为六个阶段认领 issue → 沟通 → 开发 → 准备 PR → 提交 PR → 评审。1. 认领 issue在 GitHub Issues 中找到或自行报告一个 issue它可能是 bug、缺失功能、缺失文档或体验毛刺。以评论方式声明你打算贡献解决方案如果已有人在做务必与其协调避免重复劳动。2. 尽早沟通对于较大的贡献先公开你的计划与设计方案主动征求维护者反馈——可以在 issue 里讨论也可以在 Discord。官方强调 Communicate early and often这既节省你的时间也节省维护者的时间。3. 本地开发与手动验证交互式 playground在本地开发环境里跑一条命令即可得到一个集成度完整、可交互的全组件调试沙箱dagger api call engine-dev playground terminal这条命令会依次完成构建 Dagger 引擎并把核心 SDKs 打包进镜像内部以 Dagger 服务的方式运行开发版引擎即dagger-in-dagger用 Dagger 跑 Dagger构建 Dagger CLI启动一个临时容器容器内安装好 CLI并把引擎作为 sidecar 提供打开交互式终端。从源码结构看这个能力的实现位于 engine-dev 模块。其New构造函数main.go#L19-L66会通过vcsInfo从工作区 Git 中解析 HEAD commit 与 dirty 状态并把它们作为标量而非整个 Workspace 对象注入构建对象——源码注释解释了原因避免 Workspace 对象污染内容寻址的缓存键使构建结果能在引擎重启后存活按排除法收集构建所需源码core、engine、util、dagql、cmd、sdk、modules、.dagger、.changes等目录排除sdk/**/examples等无关内容支持subnetNumber参数默认 89NetworkCidr()据此生成10.N.0.0/16网段IncrementSubnet()则用于允许嵌套 Dagger 引擎时错开网络——这正好解释了 playground 中 dagger-in-dagger 能嵌套运行的网络前提。仓库内置的 dev 脚本链仓库hack/目录还保留了不依赖工作区新特性的传统脚本入口可作为开发环境的另一条通路hack/build从本地代码构建引擎与 CLI并在宿主的 Docker 运行时中启动引擎。它通过--x-release固定到一个特定的 main 提交来驱动构建。源码注释说明了两个原因一是保证宿主机器上装的是什么版本都能跑 v1.0 工作区二是它会自动 provision 一个dagger-engine-commit容器从而构建不会运行在即将被它替换的那个引擎上避免自举悖论。该脚本还会把历史的_EXPERIMENTAL_*环境变量映射为模块参数容器名默认dagger-engine.dev、镜像名默认localhost/dagger-engine.dev、宿主平台按uname解析、GPU 支持、额外 hosts、Cloud token 等最终执行dagger --x-release ... api call dev deploy ... --output ./binhack/dev先调用hack/build构建并启动开发环境再通过hack/with-dev在环境中执行指定命令。它会先探测当前 Docker context 的DOCKER_HOST注释说明原因是dagger shell无法获取该信息并从仓库根目录执行构建以便发现dagger.toml工作区hack/with-dev设置开发环境的关键环境变量后exec目标命令包括_EXPERIMENTAL_DAGGER_CLI_BIN指向./bin/dagger、DAGGER_ENGINEcontainer://dagger-engine.dev指定使用本地构建的容器引擎、_DAGGER_TESTS_ENGINE_TAR测试用引擎 tar 包并把./bin加入PATH。也就是说无论走 playground 还是hack/dev最终形态都是本地源码构建的 CLI 本地源码构建的引擎容器二者配合完成迭代。4. 集成测试开发模块提供了几种不同粒度的测试入口跑全部核心测试dagger check test-split:*这里test-split对应 dagger.toml 中登记的.dagger/modules/test-split模块其职责是把核心测试拆分为可并行执行的批次跑当前可用的核心测试dagger api call engine-dev tests跑某个具体的核心测试例如TestModule套件中的TestNamespacingdagger api call engine-dev test --pkg./core/integration --run^TestNamespacing$跑 SDK 测试dagger check *sdk:*test*从源码看engine-dev test的完整参数面比文档示例更丰富。test.go 中Test方法L22-L79支持参数含义run只运行匹配该正则的测试skip跳过匹配该正则的测试pkg包路径默认./...failfast首个失败即中止parallel并行度默认为 CPU 数timeout整体超时race开启竞态检测count重复次数默认 1envFile通过Secret传入的测试环境变量文件testVerbose详细输出update更新 golden 文件ebpfProgs测试期间在引擎中启用的 eBPF 程序列表另外该方法标注了cachesession缓存策略会话级而Tests列出所有核心测试则委托给 Go 工具链模块执行。pkg./core/integration指向的正是仓库中庞大的核心集成测试目录如 core/integration 下的module_test.go等 515 个 Go 测试文件所在树TestModule即其中定义的一个测试套件。5. Lint运行全部 linterdagger check *:lint这一 glob 语义与 dagger.toml 中modules.golang.settings的lint字段呼应——该字段显式列出了需要 lint 的 Go 模块路径.、engine/distconsts、modules/daggerverse、sdk/go以及各.dagger/modules/*开发模块并排除了docs-dev/docusaurus等第三方生成目录。也就是说dagger check *:lint实际执行的是按工作区配置分发到各语言/工具模块的 lint 检查Go 之外还有 markdownlint、shellcheck、PsScriptAnalyzer 等均在dagger.toml的模块表中登记。6. 本地文档服务器如需本地预览文档站点dagger api call docs server updocs模块对应 dagger.toml 中的.dagger/modules/docs-dev其下还包含一个 docusaurus 子模块.dagger/modules/docs-dev/docusaurus见as-sdk模块列表文档源文件位于 docs/ 目录含current_docs、versioned_docs等。4. 准备你的 Pull Request提交 PR 之前官方给出一份必须逐项完成的 checklist生成产物并提交运行dagger generate生成 API 文档、客户端绑定client bindings及其他生成文件并把产物一并纳入 git commit。dagger.toml中modules.golang.settings.generate指明了生成输出路径如docs/current_docs/reference/cli这解释了为什么生成文件会出现在仓库中、为何必须随源码一起提交跑全量 linterdagger check *:lint全部通过用户可感知变更添加 release note运行changie new并按提示填写把生成的条目文件加入 commit对应.changes目录最终汇入 CHANGELOG.md;理解许可协议所有贡献均以 Apache License 2.0Apache-2.0作出见仓库根目录 LICENSE确认你愿意并有能力遵守协议条款DCO 签署每个 commit 必须附带 Developer Certificate of Origin做法是使用git commit -s。Signed-off-by行必须与作者的真实姓名一致提交信息规范commit message 要有用、准确、简洁。5. 提交 PR 与评审流程把特性分支推送到你的 GitHub fork向dagger/dagger仓库发起新的 Pull Request维护者会评审 PR 并可能建议修改。如需改动修改后推送到你的分支即可若与main分支产生冲突将你的分支 rebase 到最新的main上然后 force-push不熟悉 rebase 可自行查阅任意在线教程一切就绪后由维护者合并你的改动。小结Dagger 贡献工作流全景把上述要素串起来Dagger 的贡献工作流可以概括为一张命令地图阶段命令 / 动作仓库依据环境底座安装稳定版 Dagger、Changieinstall.sh本地开发沙箱dagger api call engine-dev playground terminalengine-dev 模块脚本式开发环境hack/dev/hack/build/hack/with-devhack/build、hack/with-dev核心测试dagger check test-split:*、dagger api call engine-dev test --pkg... --run...test.goSDK 测试dagger check *sdk:*test*dagger.tomlLintdagger check *:lintdagger.toml中golang.settings.lint文档预览dagger api call docs server up.dagger/modules/docs-dev生成产物dagger generate并纳入 commitgolang.settings.generate发布说明changie new产物加入 commit.dagger/modules/changelog合规Apache-2.0、git commit -sDCOLICENSE值得强调的是整套工作流的自举性质Dagger 用固定版本的稳定引擎--x-release钉住的构建作为底座在 DAG 上构建引擎 CLI 各语言 SDK再用构建产物反过来替换底座继续开发——构建永远不运行在它即将替换的那个引擎上见 hack/build 注释。理解这一点是理解 Dagger 仓库中大量.dagger/modules/*开发模块engine-dev、cli-dev、docs-dev、各*-client-dev等存在意义的关键。【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/dagger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Dagger 项目贡献者开发指南：用 Dagger 自身构建 Dagger 开发环境
Dagger 项目贡献者开发指南用 Dagger 自身构建 Dagger 开发环境【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/dagger本文基于 Dagger 仓库根目录的 CONTRIBUTING.md系统讲解如何为 Dagger 贡献代码的完整流程从初始环境搭建安装 Dagger 稳定版、Changie、Fork 仓库到日常开发playground 联调、集成测试、Lint、本地文档服务再到 Pull Request 提交与评审的规范。读完本文你将能够复现 Dagger 维护者的自举式开发工作流——用 Dagger 来开发 Dagger掌握dagger api call engine-dev ...、dagger check ...等核心开发命令并理解这些命令背后对应的仓库源码engine-dev、test-split等开发模块。如何找到值得贡献的问题官方给出的最自然的贡献起点是先把自己的工作场景放到 Dagger 上跑一遍。你在真实使用中遇到的任何问题都可以成为贡献素材例如一个文档没有回答清楚的问题文档缺口一个工具链里的 bug一个缺失的功能或毛糙的边缘体验rough edge。选定问题后按自己的难度承受力挑选合适的条目着手。贡献过程中随时可以提问维护者明确表示乐于协助但有一条原则值得记住贡献体量越大越应该尽早与维护者沟通确认方向正确避免把精力花在最终不会被合并的方案上。如果计划向各语言 SDKTypeScript、Go、Python、Elixir、Java、PHP、Rust 等本身提贡献仓库中另有专门面向 SDK 的贡献说明 sdk/CONTRIBUTING.md应先阅读该文档。初始环境搭建1. 加入社区Dagger 官方将社区协作视为项目的核心特性之一强烈建议先加入其 Discord 服务器。持续的反馈和鼓励不仅能帮你节省大量排障时间也是保持长期贡献动机的关键。2. 安装 DaggerDogfooding开发 Dagger 所用的工具——不出所料——就是 Dagger 本身官方原话To develop Dagger, we use - surprise! - Dagger.。因此第一步是安装最新的稳定版发行如果你手上有旧版本务必先升级。安装脚本可直接参考仓库内的 install.sh。之所以必须使用稳定版而非本地开发版来启动开发是因为本地构建过程需要一个底座引擎来执行构建编排这个底座由--x-release机制固定到一个已知可用的构建见下文hack/build解析。3. 安装 ChangieChangie 是一个简单的 Release Note 管理工具。凡是涉及用户可感知变更user-facing changes的贡献都需要用它生成发布说明条目。请安装最新版 Changie后续在准备 PR 时使用changie new生成条目文件。仓库根目录 dagger.toml 中登记了 changelog 模块.dagger/modules/changelog且 engine-dev 模块的源码 在打包构建源时会专门排除!.changes目录——说明 changie 生成的.changes条目是仓库内被显式管理的一类文件。4. Git 配置在 GitHub 上找到dagger/dagger仓库并点击Fork克隆你的 forkgit clone gitgithub.com:$YOUR_GITHUB_USER/dagger.git添加上游仓库为新的 remotegit remote add upstream gitgithub.com:dagger/dagger.git贡献工作流官方把工作流概括为六个阶段认领 issue → 沟通 → 开发 → 准备 PR → 提交 PR → 评审。1. 认领 issue在 GitHub Issues 中找到或自行报告一个 issue它可能是 bug、缺失功能、缺失文档或体验毛刺。以评论方式声明你打算贡献解决方案如果已有人在做务必与其协调避免重复劳动。2. 尽早沟通对于较大的贡献先公开你的计划与设计方案主动征求维护者反馈——可以在 issue 里讨论也可以在 Discord。官方强调 Communicate early and often这既节省你的时间也节省维护者的时间。3. 本地开发与手动验证交互式 playground在本地开发环境里跑一条命令即可得到一个集成度完整、可交互的全组件调试沙箱dagger api call engine-dev playground terminal这条命令会依次完成构建 Dagger 引擎并把核心 SDKs 打包进镜像内部以 Dagger 服务的方式运行开发版引擎即dagger-in-dagger用 Dagger 跑 Dagger构建 Dagger CLI启动一个临时容器容器内安装好 CLI并把引擎作为 sidecar 提供打开交互式终端。从源码结构看这个能力的实现位于 engine-dev 模块。其New构造函数main.go#L19-L66会通过vcsInfo从工作区 Git 中解析 HEAD commit 与 dirty 状态并把它们作为标量而非整个 Workspace 对象注入构建对象——源码注释解释了原因避免 Workspace 对象污染内容寻址的缓存键使构建结果能在引擎重启后存活按排除法收集构建所需源码core、engine、util、dagql、cmd、sdk、modules、.dagger、.changes等目录排除sdk/**/examples等无关内容支持subnetNumber参数默认 89NetworkCidr()据此生成10.N.0.0/16网段IncrementSubnet()则用于允许嵌套 Dagger 引擎时错开网络——这正好解释了 playground 中 dagger-in-dagger 能嵌套运行的网络前提。仓库内置的 dev 脚本链仓库hack/目录还保留了不依赖工作区新特性的传统脚本入口可作为开发环境的另一条通路hack/build从本地代码构建引擎与 CLI并在宿主的 Docker 运行时中启动引擎。它通过--x-release固定到一个特定的 main 提交来驱动构建。源码注释说明了两个原因一是保证宿主机器上装的是什么版本都能跑 v1.0 工作区二是它会自动 provision 一个dagger-engine-commit容器从而构建不会运行在即将被它替换的那个引擎上避免自举悖论。该脚本还会把历史的_EXPERIMENTAL_*环境变量映射为模块参数容器名默认dagger-engine.dev、镜像名默认localhost/dagger-engine.dev、宿主平台按uname解析、GPU 支持、额外 hosts、Cloud token 等最终执行dagger --x-release ... api call dev deploy ... --output ./binhack/dev先调用hack/build构建并启动开发环境再通过hack/with-dev在环境中执行指定命令。它会先探测当前 Docker context 的DOCKER_HOST注释说明原因是dagger shell无法获取该信息并从仓库根目录执行构建以便发现dagger.toml工作区hack/with-dev设置开发环境的关键环境变量后exec目标命令包括_EXPERIMENTAL_DAGGER_CLI_BIN指向./bin/dagger、DAGGER_ENGINEcontainer://dagger-engine.dev指定使用本地构建的容器引擎、_DAGGER_TESTS_ENGINE_TAR测试用引擎 tar 包并把./bin加入PATH。也就是说无论走 playground 还是hack/dev最终形态都是本地源码构建的 CLI 本地源码构建的引擎容器二者配合完成迭代。4. 集成测试开发模块提供了几种不同粒度的测试入口跑全部核心测试dagger check test-split:*这里test-split对应 dagger.toml 中登记的.dagger/modules/test-split模块其职责是把核心测试拆分为可并行执行的批次跑当前可用的核心测试dagger api call engine-dev tests跑某个具体的核心测试例如TestModule套件中的TestNamespacingdagger api call engine-dev test --pkg./core/integration --run^TestNamespacing$跑 SDK 测试dagger check *sdk:*test*从源码看engine-dev test的完整参数面比文档示例更丰富。test.go 中Test方法L22-L79支持参数含义run只运行匹配该正则的测试skip跳过匹配该正则的测试pkg包路径默认./...failfast首个失败即中止parallel并行度默认为 CPU 数timeout整体超时race开启竞态检测count重复次数默认 1envFile通过Secret传入的测试环境变量文件testVerbose详细输出update更新 golden 文件ebpfProgs测试期间在引擎中启用的 eBPF 程序列表另外该方法标注了cachesession缓存策略会话级而Tests列出所有核心测试则委托给 Go 工具链模块执行。pkg./core/integration指向的正是仓库中庞大的核心集成测试目录如 core/integration 下的module_test.go等 515 个 Go 测试文件所在树TestModule即其中定义的一个测试套件。5. Lint运行全部 linterdagger check *:lint这一 glob 语义与 dagger.toml 中modules.golang.settings的lint字段呼应——该字段显式列出了需要 lint 的 Go 模块路径.、engine/distconsts、modules/daggerverse、sdk/go以及各.dagger/modules/*开发模块并排除了docs-dev/docusaurus等第三方生成目录。也就是说dagger check *:lint实际执行的是按工作区配置分发到各语言/工具模块的 lint 检查Go 之外还有 markdownlint、shellcheck、PsScriptAnalyzer 等均在dagger.toml的模块表中登记。6. 本地文档服务器如需本地预览文档站点dagger api call docs server updocs模块对应 dagger.toml 中的.dagger/modules/docs-dev其下还包含一个 docusaurus 子模块.dagger/modules/docs-dev/docusaurus见as-sdk模块列表文档源文件位于 docs/ 目录含current_docs、versioned_docs等。4. 准备你的 Pull Request提交 PR 之前官方给出一份必须逐项完成的 checklist生成产物并提交运行dagger generate生成 API 文档、客户端绑定client bindings及其他生成文件并把产物一并纳入 git commit。dagger.toml中modules.golang.settings.generate指明了生成输出路径如docs/current_docs/reference/cli这解释了为什么生成文件会出现在仓库中、为何必须随源码一起提交跑全量 linterdagger check *:lint全部通过用户可感知变更添加 release note运行changie new并按提示填写把生成的条目文件加入 commit对应.changes目录最终汇入 CHANGELOG.md;理解许可协议所有贡献均以 Apache License 2.0Apache-2.0作出见仓库根目录 LICENSE确认你愿意并有能力遵守协议条款DCO 签署每个 commit 必须附带 Developer Certificate of Origin做法是使用git commit -s。Signed-off-by行必须与作者的真实姓名一致提交信息规范commit message 要有用、准确、简洁。5. 提交 PR 与评审流程把特性分支推送到你的 GitHub fork向dagger/dagger仓库发起新的 Pull Request维护者会评审 PR 并可能建议修改。如需改动修改后推送到你的分支即可若与main分支产生冲突将你的分支 rebase 到最新的main上然后 force-push不熟悉 rebase 可自行查阅任意在线教程一切就绪后由维护者合并你的改动。小结Dagger 贡献工作流全景把上述要素串起来Dagger 的贡献工作流可以概括为一张命令地图阶段命令 / 动作仓库依据环境底座安装稳定版 Dagger、Changieinstall.sh本地开发沙箱dagger api call engine-dev playground terminalengine-dev 模块脚本式开发环境hack/dev/hack/build/hack/with-devhack/build、hack/with-dev核心测试dagger check test-split:*、dagger api call engine-dev test --pkg... --run...test.goSDK 测试dagger check *sdk:*test*dagger.tomlLintdagger check *:lintdagger.toml中golang.settings.lint文档预览dagger api call docs server up.dagger/modules/docs-dev生成产物dagger generate并纳入 commitgolang.settings.generate发布说明changie new产物加入 commit.dagger/modules/changelog合规Apache-2.0、git commit -sDCOLICENSE值得强调的是整套工作流的自举性质Dagger 用固定版本的稳定引擎--x-release钉住的构建作为底座在 DAG 上构建引擎 CLI 各语言 SDK再用构建产物反过来替换底座继续开发——构建永远不运行在它即将替换的那个引擎上见 hack/build 注释。理解这一点是理解 Dagger 仓库中大量.dagger/modules/*开发模块engine-dev、cli-dev、docs-dev、各*-client-dev等存在意义的关键。【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/dagger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考