尧图网站建设 
读懂 Dagger 的 CHANGELOG格式规范、Changie 生成机制与 v0.6 至 v0.21 版本演进主线【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/daggerDagger 仓库根目录的 CHANGELOG.md 是追踪该项目 API 变化、CLI 新命令与破坏性变更的权威记录从 2023 年 7 月的 v0.6.3 一直记录到 2026 年 6 月的 v0.21.7。本篇基于该文档全文讲清它的格式规范与 Changie 自动化生成机制梳理各版本区间的重大功能里程碑模块系统、函数缓存、Workspace、Lockfile、缓存体系迁移等并对文档内若干关键条目做实操级展开帮助你在升级 Dagger 前快速判断哪些变更会影响自己的模块与 CI。格式规范与自动化生成机制CHANGELOG.md 开头的说明给出了三条基础约定记录所有值得注意的变更All notable changes格式基于Keep a Changelog的惯例版本号遵循Semantic Versioning由Changie工具自动生成。这些约定并非空话可以直接在仓库中找到对应的生成配置。根目录的 .changie.yaml 定义了整套渲染规则versionFormat: ## {{.Version}} - {{.Time.Format 2006-01-02}} kindFormat: ### {{.Kind}} changeFormat: | {{- $lines : .Body | splitn \n 2 -}} - {{ $lines._0 | trimSuffix . }} by {{.Custom.Author}} in https://github.com/dagger/dagger/pull/{{.Custom.PR}}这解释了文档中每条条目的固定形态“变更描述 by 作者 in PR 链接”其中 PR 号与作者名来自两个自定义字段Custom.PR、Custom.Author由维护者在提交变更记录时填写。版本号头部的## v0.21.7 - 2026-06-17格式则正是versionFormat模板的直接产物。.changie.yaml还定义了条目分类kinds与文档中出现的小节标题一一对应分类kind渲染出的小节标题Breaking### Breaking Changes带火焰标记最醒目Added### AddedChanged### ChangedDeprecated### DeprecatedRemoved### RemovedFixed### FixedExperimental### ExperimentalSecurity### SecurityDependencies### Dependencies每个版本小节末尾固定出现的两段内容也来自配置footerFormat模板会收集所有非维护者的外部贡献者并生成### Contributors致谢列表随后追加统一的### What to do next?引导指向官方文档与社区渠道。因此阅读时可以把这两段视为“固定样板”重点仍在前面的 Added/Changed/Fixed 条目上。一个值得注意的事实边界仓库当前的 internal/version/VERSION 文件记录的是v1.0.0-beta.13而 CHANGELOG.md 的最新条目停留在 v0.21.72026-06-17说明该快照中 CHANGELOG 尚未覆盖 1.0 beta 阶段的变更记录阅读时应以本文件所列版本范围为准。如何高效阅读一个版本条目每条 release 的组织方式高度一致可以按以下顺序提取信息先看 Breaking Changes这是唯一带火焰标记的小节列出需要迁移代码的 API 变更。Dagger 对破坏性变更的记录质量较高通常同时给出替代方案例如 v0.19.0 中移除废弃的Host.setSecretFile时明确写道“请改用file://secret provider”移除Container.build时指出“请改用Directory.dockerBuild”。再看Added新 API、新 CLI 命令、新 SDK 能力多数条目附带详细说明段见下文“深度解析”。看Changed与Fixed行为微调与缺陷修复很多 Fixed 条目包含完整的故障场景描述例如 v0.21.4 中 tarball 导出在缓存修剪后失败的复现条件对排查自身问题非常有用。留意Deprecated与Dependencies前者预告未来破坏性变更如 v0.20.4 预告 dotenv 无 scheme 的 secret 写法将要求显式 scheme后者记录 Go 版本等运行时依赖变化。版本演进主线从 v0.10.0 模块系统到 v0.21.7v0.10.02024-02-27模块与函数的诞生这是 CHANGELOG 中第一个标注为“significant”的里程碑版本引入Dagger functions 与 modules——以跨语言方式打包、共享可复用流水线函数dagger call等新 CLI 命令提供了调用模块函数的统一入口并首次引入 TUI 进度界面。此后几乎所有版本的特性都围绕这一模块体系展开。v0.11.0 – v0.12.0CLI 稳定化与“兼容模式”这一区间的主题是打磨模块开发体验与建立版本兼容机制v0.11.0 移除了--focus标志与旧进度接口加入 OTEL trace 导出v0.11.5 移除 shim、改用 dumb-initv0.12.5 加入dagger core function实验命令直接调用核心 API示例dagger core container from --addressalpine terminalv0.12.0 引入module versioning compatibility兼容模式dagger call在旧模块代码不修改的情况下仍可工作升级路径是运行dagger develop将模块dagger.json的engineVersion更新为新版本后逐步修复报错。v0.12.0 同时列出了一批 API 破坏性变更包括Container.withNewFile的contents变为必填、withExec默认跳过 entrypoint需useEntrypoint显式开启、Container.terminal返回类型改为Container、export从布尔改为返回绝对路径等。这些条目是后续版本升级时最常被检索的迁移依据。v0.13.x – v0.16.0核心 API 扩展与模块加载性能v0.13.4 调整 Git 行为默认保留.git目录可用tree的discardGitDir选项关闭并加入Service.withHostname支持服务间自定义主机名v0.13.7 起Container.withExec支持expect枚举参数声明“可接受的退出状态”并配套Container.exitCode字段v0.14.0 加入对 git credential manager 的支持使私有模块可经 PAT 加载v0.15.0 引入自定义engine.json配置文件挂载路径为~/.config/dagger/engine.json是取代旧 buildkit 风格engine.toml的新格式v0.15.2 引入dagger update命令更新dagger.json依赖并使CacheVolumes在模块间命名空间隔离。v0.16.0 是其中信息密度最高的性能版本之一。其模块加载重构给出了具体的基准对比在 Dagger 仓库自身的dagger-dev模块上测量load module时间场景v0.15.4v0.16.0提升空缓存首次执行dagger call --help1m20s1m1s约 23%无文件变更时重跑10.9s2.8s约 74%改动一个源码文件后重跑32.1s2.8s约 91%该版本的破坏性影响需要特别注意默认跳过了模块源目录之外大量隐式文件的加载。如果模块代码依赖源目录之外的本地库或父目录中的包管理文件如go.mod需要在dagger.json中显式声明 include{ include: [../go.mod, ../go.sum] }include路径相对于dagger.json所在目录支持 glob 模式如**/*.txt也可用!前缀排除如!**/foo.txt。旧的exclude字段会被dagger develop自动迁移为等价的!前缀 include 项无需手工干预。v0.17.0 – v0.19.xShell 稳定、LLM API 与函数缓存v0.17.0稳定化了Dagger Shell并加入顶层LLMAPI可将 LLM 与原生 Dagger 类型集成同一版本将引擎 Unix socket 默认路径改为/run/dagger/engine.sock旧路径保留兼容。v0.17.2加入Directory.filter替代此前Query.directory.withDirectory(, dir)这种会打断链式调用的写法。v0.18.1起 CLI/Shell 调用支持 core 函数直接调用与--no-mod/-M标志关闭自动模块加载。v0.18.4开始所有实验性 API 在 schema 中被显式标记。v0.19.1引入user defaults.env 持久化函数参数这是文档中附带完整用法说明的条目之一详见下文深度解析。v0.19.3允许模块通过引擎自调用self calls并加入withError用于在链式 with 块中抛出错误。v0.19.4引入函数级缓存控制函数调用可配置 TTL 等缓存行为命中缓存时跳过执行文档同时用醒目提示指出 v0.19.4 之前初始化的模块需要显式选择启用该行为backwards compatibility 要求。v0.20.xWorkspace、dagger up 与检查生成一体化v0.20.0加入engine local-cache prune的独立 gc 设置与--prettylogs进度格式v0.20.4是该区间最富功能的一版实验性dagger up在宿主机启动模块定义的服务含up注解、workspace/module 的services()API 与可配置端口映射、模块函数的cache指令、dagger check的--failfast与 SDK 端WithFailFast、Changeset.diffStats()结构化差异统计、DockerfileADD --unpack支持以及dagger check/dagger generate的解析范围从当前模块扩展到当前 workspacev0.20.6修复了工具链从错误源加载/解析的问题影响dagger -m remoteref场景并让 generator 的.changes/.isEmpty在.run()之前给出明确失败而非误导性结果。v0.21.xLockfile、缓存体系迁移到 DagQLv0.21.02026-05-22是近期最重要的版本包含两大主题Workspace lockfile为container.from、Git ref 等查询提供锁文件通过--lock live/--lock pinned/--lock frozen三档模式启用——live 解析并记录实时值pinned 优先使用已记录值、其余实时解析frozen 仅从.dagger/lock解析dagger lock update可刷新已记录条目并在文件缺失时创建它。该功能同时修复了远程 Git 树缓存键问题使缓存复用跟随真实 checkout 输入缓存迁移到 DagQL移除 BuildKit solver 后端缓存查找、持久化与修剪全部由 DagQL 负责配套的性能改进包括降低 bbolt/containerd 元数据开销、惰性创建 containerd 操作租约、复用池化 CNI 命名空间、批量化长withDirectory链避免二次方物化。同版本还让每个generate函数自动派生同名checkdagger check --no-generate可只运行显式标记的检查并为未发布构建加入实验性--x-releaseref参数。v0.21.1在 DagQL 中加入原生 GraphQL 接口与统一对象 IDDagger 对象通过标准Node接口与ID标量暴露同时保留旧客户端的FooID与loadFooFromID视图。v0.21.5起同时支持 Dang v1 与 v2 模块按模块engineVersion路由本地缓存在磁盘压力下自动修剪。v0.21.6为Container.from与Container.publish加入registryService选项允许使用 DaggerService提供的本地临时镜像仓库拉取/推送。v0.21.72026-06-17当前文档最新版主要是稳定性修复Dang 升级到 v2.1.1JSON 编码移入JSON命名空间顶层toJSON标记废弃、.env中非匹配变量保留为隐藏展开上下文、gitignored 目录下的重新包含文件 filesync 修复、GC 期间并发 map 迭代 panic 防护等。关键条目深度解析User defaults.env 持久化函数参数v0.19.1这是 CHANGELOG 中少见的、把完整使用手册写进 release note 的条目。核心思路把传给 Dagger 函数的参数存入本地.env文件避免每次调用重复输入同时保持函数沙箱不变。变量命名规则模块mymod的构造函数参数foo→ 变量名MYMOD_FOO模块mymod的类型foo、函数bar的参数baz→MYMOD_FOO_BAR_BAZ若.env位于模块目录内部可省略模块名前缀FOO、FOO_BAR_BAZ变量名大小写不敏感。变量值可以是任何 CLI 参数可表达的形态文档给出了九类示例INSTANCES42 # 字面量标量 usernameadmin regions[us, eu, jp] # JSON 编码数组 MYAPP_SOURCE~/dev/myapp/src # 本地目录 DOCShttps://github.com/dagger/dagger#v0.19.0:docs # 远程 git 目录 dockerSocketunix:///var/run/docker.sock # Unix socket githubTokenenv://PROD_TOKEN # 环境变量中的 secret sshKeyfile://~/.ssh/id_dsa # 文件中的 secret passwordop://my/vault/password/credential # 密码管理器引用 baseindex.docker.io/alpine:latest # 容器镜像引用 TEST_DBtcp://localhost:5432 # 宿主机 TCP 服务该条目的一个安全设计要点值得强调secret 必须以引用env://、file://、op://等 scheme形式存储即使.env意外进入版本控制泄露的也只是引用而非明文。后续版本对此持续打磨——v0.20.4 起不再展开 dotenv 字面量字面字符串保持字面、无 scheme 的 secret 写法被标记废弃v0.21.6 修复了“显式传入构造函数一个参数会丢弃其余参数默认值”的问题v0.21.7 修复了.env中非匹配变量被丢弃、导致后续变量无法对其展开的问题。Secret 的 cacheKey 语义v0.18.6Breakingv0.18.6 的破坏性变更说明了一个缓存一致性问题的完整推理过程此前 URI 型 secret如env://FOO以URI 字符串作为缓存键导致不同客户端同 URI 不同明文时错误共享缓存改为以明文的安全哈希作为缓存键后频繁轮转但语义相同的 secret如定期轮换的 token又会无谓打爆缓存。为此引入可选cacheKey参数dagger shell中dagger shell -c some-function --secret-arg $(secret env://FOO --cache-key my-cache-key)dagger call支持 URI 查询参数语法dagger call some-function --secret-arg env://FOO?cacheKeymy-cache-key。这个“问题 → 默认行为修正 → 逃生舱参数”的三段式写法是 CHANGELOG 中解释破坏性变更的典型范式升级前读透这类条目可以省去大量调试时间。Dagger Shell 的作业等待语义v0.18.11v0.18.11 的条目展示了 shell 内置命令的演进文档内直接附了可运行的示例container | from alpine | with-exec false | stdout job1$! container | from alpine | with-exec echo ok | stdout job2$! .wait $job1 $job2关键点.wait现在接受作业 ID 列表并且返回第一个失败命令的退出状态上例退出码为 1——这与 Bash 返回列表最后一个命令状态的行为不同是 shell 语义上的一个显式设计选择。同版本还加入.exit内置命令以正确传播退出码并可用$DAGGER_PROGRESS环境变量全局配置进度格式新增的dots格式面向 CI只保留日志与绿点/红叉。兼容性模式下的升级流程v0.12.0 起的通用方法CHANGELOG 在 v0.12.0 处给出了一段标准的升级指南可作为后续所有破坏性版本升级的模板引擎升级后得益于兼容模式旧模块代码的dagger call应当无需修改即可工作若出现兼容性问题多半是 bug应上报运行dagger develop将模块dagger.json的engineVersion更新到目标版本以启用新 API若代码受破坏性变更影响dagger call会开始报错逐项修复后即可恢复各条 API 变更的详细迁移说明位于对应 PR 描述中。这与后文 v0.21.5“Dang v1/v2 按engineVersion路由”、v0.13.4“旧engineVersion模块保留旧 Git 行为”等条目一脉相承engineVersion是 Dagger 做渐进式 API 演进的核心机制。给检索者与 Agent 的使用建议按 API 名检索变更CHANGELOG 条目以 API 名开头如Container.withExec、Directory.dockerBuild、GitRef.tree在 CHANGELOG.md 中直接搜索 API 名即可定位其首次引入或行为改变的版本判断升级风险先扫目标区间内的 Breaking Changes小节v0.9.0、v0.11.0、v0.11.3、v0.11.7、v0.11.8、v0.12.0、v0.13.0、v0.13.4、v0.16.0、v0.18.6、v0.18.11、v0.19.0、v0.20.1、v0.20.6 等版本含破坏性变更或引擎/客户端版本约束例如 v0.11.8 起手动连接 CLI 与引擎时两端版本必须不低于该版本交叉验证条目中的实现细节可在仓库源码中印证例如函数缓存相关实现在 dagql 包、缓存修剪相关实现在 dagql/cache_prune.go 与 internal-docs/cache_pruning.md工作区锁文件实现在 core/lockfile_update.go 与 core/workspace/lock.go版本事实边界本文所有版本事实以 CHANGELOG.md 所列 v0.6.3 至 v0.21.7 条目为准仓库快照中 internal/version/VERSION 记录的 v1.0.0-beta.13 尚无对应 changelog 条目引用 1.0 beta 阶段的行为时应以实际构建产物验证。小结CHANGELOG.md 的价值不仅在于“记了什么”更在于它呈现了 Dagger 三条贯穿性的工程主线以engineVersion兼容模式托底的渐进式 API 演进、以dagger develop/dagger call为核心的模块化工具链、以及从 BuildKit solver 到 DagQL 的缓存体系内化。配合 .changie.yaml 的模板化生成每条变更都带有可追溯的 PR 与作者信息使其成为 Agent 和开发者定位“某个行为从哪个版本开始变化”的最可靠入口。【免费下载链接】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 的 CHANGELOG：格式规范、Changie 生成机制与 v0.6 至 v0.21 版本演进主线
读懂 Dagger 的 CHANGELOG格式规范、Changie 生成机制与 v0.6 至 v0.21 版本演进主线【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/daggerDagger 仓库根目录的 CHANGELOG.md 是追踪该项目 API 变化、CLI 新命令与破坏性变更的权威记录从 2023 年 7 月的 v0.6.3 一直记录到 2026 年 6 月的 v0.21.7。本篇基于该文档全文讲清它的格式规范与 Changie 自动化生成机制梳理各版本区间的重大功能里程碑模块系统、函数缓存、Workspace、Lockfile、缓存体系迁移等并对文档内若干关键条目做实操级展开帮助你在升级 Dagger 前快速判断哪些变更会影响自己的模块与 CI。格式规范与自动化生成机制CHANGELOG.md 开头的说明给出了三条基础约定记录所有值得注意的变更All notable changes格式基于Keep a Changelog的惯例版本号遵循Semantic Versioning由Changie工具自动生成。这些约定并非空话可以直接在仓库中找到对应的生成配置。根目录的 .changie.yaml 定义了整套渲染规则versionFormat: ## {{.Version}} - {{.Time.Format 2006-01-02}} kindFormat: ### {{.Kind}} changeFormat: | {{- $lines : .Body | splitn \n 2 -}} - {{ $lines._0 | trimSuffix . }} by {{.Custom.Author}} in https://github.com/dagger/dagger/pull/{{.Custom.PR}}这解释了文档中每条条目的固定形态“变更描述 by 作者 in PR 链接”其中 PR 号与作者名来自两个自定义字段Custom.PR、Custom.Author由维护者在提交变更记录时填写。版本号头部的## v0.21.7 - 2026-06-17格式则正是versionFormat模板的直接产物。.changie.yaml还定义了条目分类kinds与文档中出现的小节标题一一对应分类kind渲染出的小节标题Breaking### Breaking Changes带火焰标记最醒目Added### AddedChanged### ChangedDeprecated### DeprecatedRemoved### RemovedFixed### FixedExperimental### ExperimentalSecurity### SecurityDependencies### Dependencies每个版本小节末尾固定出现的两段内容也来自配置footerFormat模板会收集所有非维护者的外部贡献者并生成### Contributors致谢列表随后追加统一的### What to do next?引导指向官方文档与社区渠道。因此阅读时可以把这两段视为“固定样板”重点仍在前面的 Added/Changed/Fixed 条目上。一个值得注意的事实边界仓库当前的 internal/version/VERSION 文件记录的是v1.0.0-beta.13而 CHANGELOG.md 的最新条目停留在 v0.21.72026-06-17说明该快照中 CHANGELOG 尚未覆盖 1.0 beta 阶段的变更记录阅读时应以本文件所列版本范围为准。如何高效阅读一个版本条目每条 release 的组织方式高度一致可以按以下顺序提取信息先看 Breaking Changes这是唯一带火焰标记的小节列出需要迁移代码的 API 变更。Dagger 对破坏性变更的记录质量较高通常同时给出替代方案例如 v0.19.0 中移除废弃的Host.setSecretFile时明确写道“请改用file://secret provider”移除Container.build时指出“请改用Directory.dockerBuild”。再看Added新 API、新 CLI 命令、新 SDK 能力多数条目附带详细说明段见下文“深度解析”。看Changed与Fixed行为微调与缺陷修复很多 Fixed 条目包含完整的故障场景描述例如 v0.21.4 中 tarball 导出在缓存修剪后失败的复现条件对排查自身问题非常有用。留意Deprecated与Dependencies前者预告未来破坏性变更如 v0.20.4 预告 dotenv 无 scheme 的 secret 写法将要求显式 scheme后者记录 Go 版本等运行时依赖变化。版本演进主线从 v0.10.0 模块系统到 v0.21.7v0.10.02024-02-27模块与函数的诞生这是 CHANGELOG 中第一个标注为“significant”的里程碑版本引入Dagger functions 与 modules——以跨语言方式打包、共享可复用流水线函数dagger call等新 CLI 命令提供了调用模块函数的统一入口并首次引入 TUI 进度界面。此后几乎所有版本的特性都围绕这一模块体系展开。v0.11.0 – v0.12.0CLI 稳定化与“兼容模式”这一区间的主题是打磨模块开发体验与建立版本兼容机制v0.11.0 移除了--focus标志与旧进度接口加入 OTEL trace 导出v0.11.5 移除 shim、改用 dumb-initv0.12.5 加入dagger core function实验命令直接调用核心 API示例dagger core container from --addressalpine terminalv0.12.0 引入module versioning compatibility兼容模式dagger call在旧模块代码不修改的情况下仍可工作升级路径是运行dagger develop将模块dagger.json的engineVersion更新为新版本后逐步修复报错。v0.12.0 同时列出了一批 API 破坏性变更包括Container.withNewFile的contents变为必填、withExec默认跳过 entrypoint需useEntrypoint显式开启、Container.terminal返回类型改为Container、export从布尔改为返回绝对路径等。这些条目是后续版本升级时最常被检索的迁移依据。v0.13.x – v0.16.0核心 API 扩展与模块加载性能v0.13.4 调整 Git 行为默认保留.git目录可用tree的discardGitDir选项关闭并加入Service.withHostname支持服务间自定义主机名v0.13.7 起Container.withExec支持expect枚举参数声明“可接受的退出状态”并配套Container.exitCode字段v0.14.0 加入对 git credential manager 的支持使私有模块可经 PAT 加载v0.15.0 引入自定义engine.json配置文件挂载路径为~/.config/dagger/engine.json是取代旧 buildkit 风格engine.toml的新格式v0.15.2 引入dagger update命令更新dagger.json依赖并使CacheVolumes在模块间命名空间隔离。v0.16.0 是其中信息密度最高的性能版本之一。其模块加载重构给出了具体的基准对比在 Dagger 仓库自身的dagger-dev模块上测量load module时间场景v0.15.4v0.16.0提升空缓存首次执行dagger call --help1m20s1m1s约 23%无文件变更时重跑10.9s2.8s约 74%改动一个源码文件后重跑32.1s2.8s约 91%该版本的破坏性影响需要特别注意默认跳过了模块源目录之外大量隐式文件的加载。如果模块代码依赖源目录之外的本地库或父目录中的包管理文件如go.mod需要在dagger.json中显式声明 include{ include: [../go.mod, ../go.sum] }include路径相对于dagger.json所在目录支持 glob 模式如**/*.txt也可用!前缀排除如!**/foo.txt。旧的exclude字段会被dagger develop自动迁移为等价的!前缀 include 项无需手工干预。v0.17.0 – v0.19.xShell 稳定、LLM API 与函数缓存v0.17.0稳定化了Dagger Shell并加入顶层LLMAPI可将 LLM 与原生 Dagger 类型集成同一版本将引擎 Unix socket 默认路径改为/run/dagger/engine.sock旧路径保留兼容。v0.17.2加入Directory.filter替代此前Query.directory.withDirectory(, dir)这种会打断链式调用的写法。v0.18.1起 CLI/Shell 调用支持 core 函数直接调用与--no-mod/-M标志关闭自动模块加载。v0.18.4开始所有实验性 API 在 schema 中被显式标记。v0.19.1引入user defaults.env 持久化函数参数这是文档中附带完整用法说明的条目之一详见下文深度解析。v0.19.3允许模块通过引擎自调用self calls并加入withError用于在链式 with 块中抛出错误。v0.19.4引入函数级缓存控制函数调用可配置 TTL 等缓存行为命中缓存时跳过执行文档同时用醒目提示指出 v0.19.4 之前初始化的模块需要显式选择启用该行为backwards compatibility 要求。v0.20.xWorkspace、dagger up 与检查生成一体化v0.20.0加入engine local-cache prune的独立 gc 设置与--prettylogs进度格式v0.20.4是该区间最富功能的一版实验性dagger up在宿主机启动模块定义的服务含up注解、workspace/module 的services()API 与可配置端口映射、模块函数的cache指令、dagger check的--failfast与 SDK 端WithFailFast、Changeset.diffStats()结构化差异统计、DockerfileADD --unpack支持以及dagger check/dagger generate的解析范围从当前模块扩展到当前 workspacev0.20.6修复了工具链从错误源加载/解析的问题影响dagger -m remoteref场景并让 generator 的.changes/.isEmpty在.run()之前给出明确失败而非误导性结果。v0.21.xLockfile、缓存体系迁移到 DagQLv0.21.02026-05-22是近期最重要的版本包含两大主题Workspace lockfile为container.from、Git ref 等查询提供锁文件通过--lock live/--lock pinned/--lock frozen三档模式启用——live 解析并记录实时值pinned 优先使用已记录值、其余实时解析frozen 仅从.dagger/lock解析dagger lock update可刷新已记录条目并在文件缺失时创建它。该功能同时修复了远程 Git 树缓存键问题使缓存复用跟随真实 checkout 输入缓存迁移到 DagQL移除 BuildKit solver 后端缓存查找、持久化与修剪全部由 DagQL 负责配套的性能改进包括降低 bbolt/containerd 元数据开销、惰性创建 containerd 操作租约、复用池化 CNI 命名空间、批量化长withDirectory链避免二次方物化。同版本还让每个generate函数自动派生同名checkdagger check --no-generate可只运行显式标记的检查并为未发布构建加入实验性--x-releaseref参数。v0.21.1在 DagQL 中加入原生 GraphQL 接口与统一对象 IDDagger 对象通过标准Node接口与ID标量暴露同时保留旧客户端的FooID与loadFooFromID视图。v0.21.5起同时支持 Dang v1 与 v2 模块按模块engineVersion路由本地缓存在磁盘压力下自动修剪。v0.21.6为Container.from与Container.publish加入registryService选项允许使用 DaggerService提供的本地临时镜像仓库拉取/推送。v0.21.72026-06-17当前文档最新版主要是稳定性修复Dang 升级到 v2.1.1JSON 编码移入JSON命名空间顶层toJSON标记废弃、.env中非匹配变量保留为隐藏展开上下文、gitignored 目录下的重新包含文件 filesync 修复、GC 期间并发 map 迭代 panic 防护等。关键条目深度解析User defaults.env 持久化函数参数v0.19.1这是 CHANGELOG 中少见的、把完整使用手册写进 release note 的条目。核心思路把传给 Dagger 函数的参数存入本地.env文件避免每次调用重复输入同时保持函数沙箱不变。变量命名规则模块mymod的构造函数参数foo→ 变量名MYMOD_FOO模块mymod的类型foo、函数bar的参数baz→MYMOD_FOO_BAR_BAZ若.env位于模块目录内部可省略模块名前缀FOO、FOO_BAR_BAZ变量名大小写不敏感。变量值可以是任何 CLI 参数可表达的形态文档给出了九类示例INSTANCES42 # 字面量标量 usernameadmin regions[us, eu, jp] # JSON 编码数组 MYAPP_SOURCE~/dev/myapp/src # 本地目录 DOCShttps://github.com/dagger/dagger#v0.19.0:docs # 远程 git 目录 dockerSocketunix:///var/run/docker.sock # Unix socket githubTokenenv://PROD_TOKEN # 环境变量中的 secret sshKeyfile://~/.ssh/id_dsa # 文件中的 secret passwordop://my/vault/password/credential # 密码管理器引用 baseindex.docker.io/alpine:latest # 容器镜像引用 TEST_DBtcp://localhost:5432 # 宿主机 TCP 服务该条目的一个安全设计要点值得强调secret 必须以引用env://、file://、op://等 scheme形式存储即使.env意外进入版本控制泄露的也只是引用而非明文。后续版本对此持续打磨——v0.20.4 起不再展开 dotenv 字面量字面字符串保持字面、无 scheme 的 secret 写法被标记废弃v0.21.6 修复了“显式传入构造函数一个参数会丢弃其余参数默认值”的问题v0.21.7 修复了.env中非匹配变量被丢弃、导致后续变量无法对其展开的问题。Secret 的 cacheKey 语义v0.18.6Breakingv0.18.6 的破坏性变更说明了一个缓存一致性问题的完整推理过程此前 URI 型 secret如env://FOO以URI 字符串作为缓存键导致不同客户端同 URI 不同明文时错误共享缓存改为以明文的安全哈希作为缓存键后频繁轮转但语义相同的 secret如定期轮换的 token又会无谓打爆缓存。为此引入可选cacheKey参数dagger shell中dagger shell -c some-function --secret-arg $(secret env://FOO --cache-key my-cache-key)dagger call支持 URI 查询参数语法dagger call some-function --secret-arg env://FOO?cacheKeymy-cache-key。这个“问题 → 默认行为修正 → 逃生舱参数”的三段式写法是 CHANGELOG 中解释破坏性变更的典型范式升级前读透这类条目可以省去大量调试时间。Dagger Shell 的作业等待语义v0.18.11v0.18.11 的条目展示了 shell 内置命令的演进文档内直接附了可运行的示例container | from alpine | with-exec false | stdout job1$! container | from alpine | with-exec echo ok | stdout job2$! .wait $job1 $job2关键点.wait现在接受作业 ID 列表并且返回第一个失败命令的退出状态上例退出码为 1——这与 Bash 返回列表最后一个命令状态的行为不同是 shell 语义上的一个显式设计选择。同版本还加入.exit内置命令以正确传播退出码并可用$DAGGER_PROGRESS环境变量全局配置进度格式新增的dots格式面向 CI只保留日志与绿点/红叉。兼容性模式下的升级流程v0.12.0 起的通用方法CHANGELOG 在 v0.12.0 处给出了一段标准的升级指南可作为后续所有破坏性版本升级的模板引擎升级后得益于兼容模式旧模块代码的dagger call应当无需修改即可工作若出现兼容性问题多半是 bug应上报运行dagger develop将模块dagger.json的engineVersion更新到目标版本以启用新 API若代码受破坏性变更影响dagger call会开始报错逐项修复后即可恢复各条 API 变更的详细迁移说明位于对应 PR 描述中。这与后文 v0.21.5“Dang v1/v2 按engineVersion路由”、v0.13.4“旧engineVersion模块保留旧 Git 行为”等条目一脉相承engineVersion是 Dagger 做渐进式 API 演进的核心机制。给检索者与 Agent 的使用建议按 API 名检索变更CHANGELOG 条目以 API 名开头如Container.withExec、Directory.dockerBuild、GitRef.tree在 CHANGELOG.md 中直接搜索 API 名即可定位其首次引入或行为改变的版本判断升级风险先扫目标区间内的 Breaking Changes小节v0.9.0、v0.11.0、v0.11.3、v0.11.7、v0.11.8、v0.12.0、v0.13.0、v0.13.4、v0.16.0、v0.18.6、v0.18.11、v0.19.0、v0.20.1、v0.20.6 等版本含破坏性变更或引擎/客户端版本约束例如 v0.11.8 起手动连接 CLI 与引擎时两端版本必须不低于该版本交叉验证条目中的实现细节可在仓库源码中印证例如函数缓存相关实现在 dagql 包、缓存修剪相关实现在 dagql/cache_prune.go 与 internal-docs/cache_pruning.md工作区锁文件实现在 core/lockfile_update.go 与 core/workspace/lock.go版本事实边界本文所有版本事实以 CHANGELOG.md 所列 v0.6.3 至 v0.21.7 条目为准仓库快照中 internal/version/VERSION 记录的 v1.0.0-beta.13 尚无对应 changelog 条目引用 1.0 beta 阶段的行为时应以实际构建产物验证。小结CHANGELOG.md 的价值不仅在于“记了什么”更在于它呈现了 Dagger 三条贯穿性的工程主线以engineVersion兼容模式托底的渐进式 API 演进、以dagger develop/dagger call为核心的模块化工具链、以及从 BuildKit solver 到 DagQL 的缓存体系内化。配合 .changie.yaml 的模板化生成每条变更都带有可追溯的 PR 与作者信息使其成为 Agent 和开发者定位“某个行为从哪个版本开始变化”的最可靠入口。【免费下载链接】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），仅供参考