anodizer

Anodizer 会读取声明式配置文件，并通过一条 anodizer release 命令完成整个发布流程：构建、归档、校验和、生成变更日志、签名、发布、推送到仓库并公告。它围绕 Rust 生态构建，支持 Cargo 工作区、感知 Cargo.lock 的版本升级、crates.io，以及字节级可复现的产物。

请参阅哪些功能可用（附证据），查看各项功能的状态——每一项“已上线”的声明都链接到真实发布的产物，供你自行验证。

为什么选择 anodizer？

你的发布流程面向的是 Cargo 工作区，而不是一堆互不相关的二进制文件。anodizer 从设计之初就以此为核心。

• 它懂 Cargo。 支持按 crate 设置发布节奏和标签，并提供标签解析器，让单个 crate 和包含三十个 crate 的单体仓库共用一份配置。anodizer tag 和 anodizer bump 会改写 Cargo.toml 和 Cargo.lock，然后提交并打标签——默认在本地执行；使用 --push 时，则会以原子方式推送升级提交和标签——不会留下孤立的升级提交，不必手写 git push，也不会导致锁文件版本不一致。
• 按正确顺序发布到 crates.io。 根据依赖关系排序，并轮询稀疏索引，让每个 crate 等待其依赖项完成传播后再发布——这样工作区发布就不会因竞速而暂时出现“找不到版本”的问题。
• 交叉编译，无需承担工具链负担。 通过 cargo-zigbuild 或 cross，即可在一台机器上构建 musl、glibc、Windows 和 macOS 目标。无需反复执行 rustup target add，也不必费心维护每个目标专属的 CI 分片。
• 可复现，并且有据可证。 默认生成确定性产物，然后通过 anodizer check determinism 重新构建并逐字节比较。这样，“可复现”就成了 CI 强制验证的事实，而不只是发布说明中的一句承诺。
• 签名和证明是一等功能。 通过 cosign + GPG 为二进制文件、归档、校验和及镜像签名，并提供 SLSA 风格的构建来源证明——只需几行配置即可完成接入。

此外，还有 Rust 作者实际会遇到的各种细节：为每个 crate 生成 README、直接从配置派生 cargo-binstall 元数据（无需手动维护可能返回 404 的 pkg-url）、使用 version_files 将文档和安装脚本固定到已发布的版本，以及在发布后进行安装冒烟测试，抢在用户发现问题之前捕获损坏的产物。

已经熟悉 GoReleaser？anodizer 的 {{ .Field }} 模板语法会让你倍感亲切。正从 cargo-dist、release-plz 或 cargo-release 迁移？迁移指南可帮你直接转换现有配置。

功能

构建

• 通过 cargo-zigbuild、cross 或原生 cargo build 进行跨平台构建
• 每次构建的钩子（前置／后置）、环境变量、功能标志和目标覆盖项
• 使用 UPX 压缩二进制文件，并按目标筛选
• 支持工作区，每个 crate 可独立设置发布周期

打包

• 支持 tar.gz、tar.xz、tar.zst、zip、gz 或原始二进制格式的归档，并支持按操作系统覆盖配置
• 通过 nFPM 创建 Linux 软件包（.deb、.rpm、.apk、.archlinux、.ipk），支持完整生命周期脚本
• 使用 prime-dir 架构创建 Snapcraft snaps
• macOS DMG 磁盘映像和 PKG 安装程序
• Windows MSI 和 NSIS 安装程序
• Flatpak 软件包
• AppImage 便携式 Linux 应用程序
• Makeself 自解压归档
• 生成 curl | sh 安装脚本——根据构建／归档配置生成按平台划分的资源表（无需手动维护可能返回 404 的 URL），并设有校验和验证关卡
• 源 RPM（.src.rpm）
• 支持文件筛选的源代码归档
• 生成 SBOM（CycloneDX/SPDX）
• 支持 SHA-256、SHA-512、SHA3、BLAKE2b、BLAKE2s、BLAKE3、CRC32、MD5 等校验和——可合并生成，或为每个制品分别生成 sidecar 文件，支持裸格式或 coreutils（shasum -c）格式

签名

• 使用 GPG 和 cosign 为二进制文件、归档、校验和、Docker 镜像和 SBOM 签名
• 使用现有 git 签名密钥为 git 标签签名（GPG 或 SSH）
• 多个相互独立的签名配置
• 通过模板表达式实现条件签名
• 为二进制文件和制品生成构建来源证明（SLSA 风格）

发布

• 发布到 GitHub/GitLab/Gitea Releases，支持上传资源、检测草稿／预发布版本以及页眉／页脚模板；仓库所有者和名称默认取自 origin 远程
• 发布到 crates.io，支持依赖感知排序和索引轮询
• 生成 Homebrew formula 和 cask
• 提交 Homebrew-core formula 更新 PR（更新现有的 homebrew-core formula）
• 生成 Scoop 清单
• 生成 Chocolatey 软件包
• 生成 Winget 清单
• 生成 AUR PKGBUILD 和 .SRCINFO
• 生成 Krew 插件清单
• 生成 Nix derivation
• 注册到 SchemaStore catalog，为配置文件提供编辑器自动补全
• 发布 MCP registry 服务清单（Model Context Protocol）
• 通过 docker buildx 构建 Docker 多架构镜像
• 上传到 Blob 存储（S3、GCS、Azure）
• NPM 平台专用二进制软件包和 PyPI 原生二进制 wheel
• 为 crates.io、npm（含来源证明）和 PyPI 提供无密钥 OIDC Trusted Publishing——无需存储注册表令牌
• Artifactory、Cloudsmith、Fury、Docker Hub
• 自定义发布命令

通知

• Discord、Slack、Telegram、Teams、Mattermost
• Email、Reddit、Twitter/X、Mastodon、Bluesky、LinkedIn
• OpenCollective、Discourse
• 支持自定义请求头和模板的通用 Webhook

高级功能

• Tera 模板（类似 Jinja2），兼容 GoReleaser 的 {{ .Field }} 语法
• 使用基于日期的版本号进行 Nightly 构建
• 用于共享配置的配置文件 include
• 支持拆分／合并 CI，便于扇出并行构建
• 支持 Monorepo，工作区可独立配置
• 根据提交消息指令自动打标签
• 通过 mod_timestamp 和 builds_info 实现可复现构建
• 同步版本字符串文件（version_files），在标签发布时让文档、脚本和清单保持一致
• 跨发布渠道提升版本（anodizer promote）——无需重新构建，即可将已发布的制品切换到稳定渠道（snapcraft channels、npm dist-tags、OCI 浮动标签、GitHub 预发布版本）
• 发布后验证，包含安装冒烟测试
• GitHub Actions 作业摘要列出本次运行发布的每个版本、拉取请求、软件包和镜像
• 提供 JSON Schema，用于编辑器自动补全和验证
• 内置 MCP 服务（anodizer mcp），将 CLI 作为带注释的工具提供给 AI 助手

安装

Homebrew（macOS/Linux）

brew install tj-smith47/tap/anodizer

Cargo

cargo install anodizer

从源代码安装

git clone https://github.com/tj-smith47/anodizer.git
cd anodizer
cargo install --path crates/cli

快速开始

# Generate a starter config from your Cargo workspace
anodizer init > .anodizer.yaml

# Validate your config
anodizer check

# Check that required tools are available
anodizer healthcheck

# Build a snapshot (no publishing)
anodizer release --snapshot

# Dry run (full pipeline, no side effects)
anodizer release --dry-run

# Bump crate versions from Conventional Commits — rewrites Cargo.toml + Cargo.lock,
# no tag (tag separately, or let the release workflow tag for you)
anodizer bump --dry-run --output json         # preview the per-crate plan as JSON
anodizer bump                                 # infer patch/minor/major per crate since its last tag
anodizer bump minor --package mycrate         # force a level for one crate
anodizer bump --workspace --commit --changelog  # bump every member, commit, refresh CHANGELOG.md
anodizer bump --pre rc.1                       # append a prerelease identifier (0.5.0-rc.1)

# Auto-tag from commit directives
# (Conventional Commits: feat: → minor, fix: → patch, BREAKING CHANGE: → major)
anodizer tag --dry-run                         # preview what tag would be created
anodizer tag --push --changelog                # tag + refresh changelog + push (triggers the release)
anodizer tag --sign --push                     # signed annotated tag (uses git user.signingkey)
anodizer tag --custom-tag v0.1.0               # force a tag value, bypassing bump derivation
anodizer tag --version 1.2.3 --crate mycrate   # pin an exact version for recovery (per-crate mode)
anodizer tag rollback "$GITHUB_SHA"            # delete anodizer-managed tags at a SHA + revert the bump

# Resume a stalled release from a populated dist/ — no rebuild
anodizer continue                              # resume the publish-only pipeline after a transient failure
anodizer continue --merge                      # fan-in split-build workers, then sign/checksum/release/publish
anodizer continue --skip npm,announce          # resume but skip named stages/publishers

# Run only the publish stages (release / blob / publish) from a completed dist/
anodizer publish --publishers homebrew,scoop   # publish to a subset of configured publishers
anodizer publish --dry-run                     # preview the publish chain with no side effects

# Promote an already-published artifact to a stable track — no rebuild
anodizer promote --to stable                                  # promote the newest prerelease artifact
anodizer promote --to stable --from candidate --dry-run       # preview promoting from a named source track
anodizer promote --to stable --version v1.2.0 \
  --publishers snapcraft,npm                                  # promote a pinned version on chosen publishers

对于基于 CI 的发布，请将 GITHUB_TOKEN（或 ANODIZER_GITHUB_TOKEN）设为机密，发布流水线会自动获取它。

配置

Anodizer 在项目根目录中使用 .anodizer.yaml（或 .anodizer.toml）。添加 schema 注释即可启用编辑器自动补全：

# yaml-language-server: $schema=https://tj-smith47.github.io/anodizer/schema.json

project_name: myapp

defaults:
  targets:
    - x86_64-unknown-linux-gnu
    - aarch64-unknown-linux-gnu
    - x86_64-apple-darwin
    - aarch64-apple-darwin
    - x86_64-pc-windows-msvc
  cross: auto

crates:
  - name: myapp
    path: "."
    tag_template: "v{{ Version }}"
    builds:
      - binary: myapp
    archives:
      - name_template: "{{ ProjectName }}-{{ Version }}-{{ Os }}-{{ Arch }}"
        files: [LICENSE, README.md]
    release:
      github:
        owner: myorg    # optional: read from the origin remote when omitted
        name: myapp
    publish:
      cargo: {}
      homebrew_cask:
        repository:
          owner: myorg
          name: homebrew-tap
        binaries: [myapp]

所有可用字段、变量和筛选器，请参阅完整配置参考和模板参考。

实际采用案例：cfgd

cfgd——一种声明式、GitOps 风格的机器配置管理工具——是 anodizer 的首个实际采用者，并以实际使用的方式测试每个已发布的发布器。它是一个包含 4 个 crate 的工作区（共享库 + CLI + Kubernetes 运算符 + CSI 驱动程序），可发布到 crates.io（按依赖关系排序）、GitHub Releases、Homebrew、Scoop、Chocolatey、Winget、Snap Store、Krew、GHCR，并通过 cargo binstall 发布——所有操作只需一个 .anodizer.yaml 和一次标签推送即可完成。

以下是 cfgd 的 .anodizer.yaml 的精简片段：

workspaces:
  - name: cfgd-core
    crates:
      - name: cfgd-core
        tag_template: "core-v{{ Version }}"
        version_sync: { enabled: true, mode: cargo }

  - name: cfgd
    crates:
      - name: cfgd
        depends_on: [cfgd-core]
        version_sync: { enabled: true, mode: cargo }
        universal_binaries:
          - name_template: "{{ ProjectName }}"
            replace: false
        binstall:
          enabled: true   # pkg-url + per-target overrides derived from archive.name_template
  # ... cfgd-operator, cfgd-csi

可用功能（含证明）中的每个单元格都链接到对应功能的 cfgd 实际发布产物——验证依据就在其中。

GitHub Actions

Anodizer 提供了官方 Action：tj-smith47/anodizer-action。本仓库在自己的 release.yml 中也使用了它：

# not an anodizer config
name: Release

on:
  push:
    tags: ["v*"]

permissions:
  contents: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - uses: dtolnay/rust-toolchain@stable

      - name: Release
        uses: tj-smith47/anodizer-action@v1
        with:
          version: latest        # accepts `latest`, `nightly`, or an exact tag (e.g. `v0.5.0`). Pin in production.
          auto-install: true     # auto-detect nfpm/makeself/snapcraft/cosign/etc from .anodizer.yaml
          args: release --clean
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

有关拆分／合并扇出、导入 GPG 密钥、登录注册表和各平台变体，请参阅 anodizer-action 以及本仓库当前的 .github/workflows/release.yml。

MCP 服务

anodizer mcp 可通过 stdio 或可流式传输的 HTTP，将 CLI 提供给任何 MCP 客户端——Claude Desktop、VS Code、Cursor、Zed——底层基于 brontes 构建。每个子命令都会成为一个工具，其标志会作为 JSON Schema 提供，因此助手无需手动编写任何包装代码即可驱动发布。

$ anodizer mcp claude enable      # register with Claude Desktop (also: vscode, cursor, zed)
$ anodizer mcp start              # stdio, for a client that spawns the process
$ anodizer mcp stream --port 8080 # streamable HTTP, for a shared/remote client
$ anodizer mcp tools              # dump the tool list to mcp-tools.json for inspection

默认提供 23 个工具（completion 和 man 属于 shell 提示词产物，因此不予提供）。三组工具可为不应看到全部工具的客户端缩小范围：

选择方式	工具	覆盖范围
(默认)	23	完整命令树
--group inspect	9	check config、check version-files、healthcheck、preflight、jsonschema、resolve-tag、targets、vocabulary、tools
--group author	5	init、changelog、bump、tag、tag rollback
--group ship	7	build、release、publish、promote、continue、announce、notify

相同的 --group／--command／--tool 标志也适用于 mcp start 和 mcp stream，编辑器安装器也会转发这些标志——anodizer mcp claude enable --group inspect 可注册一个只读助手。每个选项都有对应的 --hide- 标志，可从完整列表中移除项目，而不是选择特定项目。

每个工具都带有客户端可据以设置门控的注解，因此客户端在运行之前即可区分配置验证和发布：

注解	命令
readOnlyHint	inspect 组——只有 preflight 会设置 openWorldHint
幂等本地写入	build、changelog、check determinism、init、tag
幂等 + openWorldHint	announce、continue、notify、promote、publish、release
非幂等	bump——重复执行会使版本号递增两次
destructiveHint	tag rollback——撤销发布器操作、删除标签并重写历史记录

通常需要运行数分钟的六个命令——build、check determinism、continue、promote、publish、release——会返回任务句柄，而不是保持请求打开。因此，支持 MCP tasks 扩展的客户端可以轮询、流式接收进度，并取消正在运行的发布。

CLI 参考

anodizer release       Full release pipeline (--snapshot, --dry-run, --split/--merge, --publish-only)
anodizer tag           Auto-tag from commit directives
anodizer tag rollback  Delete anodizer-managed tags at a SHA and revert the bump commit
anodizer bump          Bump crate versions (Conventional Commits → semver level) without tagging
anodizer promote       Promote a published artifact to a stable track without rebuilding
anodizer continue      Resume a stalled or split release from a populated dist/ (--merge to fan-in)
anodizer publish       Run only the publish stages (release, blob, publish) from a completed dist/
anodizer check         Validate configuration + run determinism harness
anodizer preflight     Run the release preflight without releasing (tools, secrets, publisher credentials and state)
anodizer init          Generate starter .anodizer.yaml
anodizer healthcheck   Probe external tools (nfpm, cosign, ...)

失败处理在进程内完成：anodizer release 失败时会自行执行 release.on_failure 策略（默认为 rollback——删除标签、 撤销版本提升；一旦 crates.io 等不可逆发布平台完成发布，便会自动降级为 hold），因此发布工作流无需添加 if: failure() 恢复步骤。anodizer tag rollback "$GITHUB_SHA" 是 被终止或暂停的运行的手动恢复命令。有关标志矩阵和恢复流程，请参阅 发布韧性。

完整参考：anodizer --help 或文档网站。

文档

完整文档请访问 tj-smith47.github.io/anodizer。

运维指南：

• 发布韧性指南 - 三组发布平台分发、提交者门控、回滚、从运行记录重放
• 确定性指南 - 字节稳定性契约、anodizer check determinism 测试框架、运行时允许列表

许可证

可任选以下许可证之一：

• Apache License 2.0（LICENSE-APACHE 或 https://www.apache.org/licenses/LICENSE-2.0）
• MIT license（LICENSE-MIT 或 https://opensource.org/licenses/MIT）

由你选择。

除非你明确声明另有规定，否则你为纳入本作品而有意提交的任何贡献（定义见 Apache-2.0 许可证）均按上述双重许可证授权，且不附加任何条款或条件。