Gleam 编译器版本发布全流程指南从版本号更新到 CI 自动发布【免费下载链接】gleam⭐️ A friendly language for building type-safe, scalable systems!项目地址: https://gitcode.com/GitHub_Trending/gl/gleam本篇指南围绕 Gleam 编译器仓库根目录下的 RELEASE.md 发布清单展开系统梳理该开源项目从代码就绪到用户拿到安装包的完整发布链路。你将掌握版本号如何同步、make test build本地验证、Git 标签触发机制、CI 自动构建与发布草稿的生成原理以及发布后如何交付容器镜像与补充文档可直接用于维护该仓库或借鉴到自己的 Rust 项目发布流程中。发布清单概览一条 8 步的发布流水线RELEASE.md 全文只有一份简洁的清单但它浓缩了整个 Gleam 项目对外发版的全部动作。从仓库源码与工作流配置可以还原出这份清单背后是一条文档先行 → 版本同步 → 本地验证 → Git 标签触发 → CI 构建 → 人工确认发布 → 对外分享的完整流水线。其 8 个步骤为在官网上撰写发布公告release post。更新官网上的文档语言服务器、gleam.toml 等。更新每个Cargo.toml中的版本号。运行make test build。Git 提交、打标签、推送、推送标签。等待 CI 发布构建完成。在 GitHub 上从 CI 生成的草稿发布正式 Release。分享官网发布公告。下面结合仓库中的 Makefile、Cargo.toml、.github/workflows/release.yaml 等真实实现逐条展开讲解每一步该做什么、为什么做、底层发生了什么。第 12 步发布公告与官网文档先行清单把写发布公告和更新文档放在最前面而不是放到代码改动之后这体现了 Gleam 团队发布即对外承诺的做法先确定本次版本对外讲述的故事新特性、破坏性变更再让代码与之一致。发布公告说明本次版本面向用户的核心亮点。仓库的 CHANGELOG.md 维护着未发布变更Unreleased区块而 changelog/ 目录按版本存放v1.1.mdv1.18.md的历史变更记录可以作为公告素材的直接来源。文档更新清单特别点名了语言服务器与gleam.toml等主题。例如语言服务器的新能力对应的实现位于 language-server/src配置项解析在 compiler-core/src/config.rs。凡是本次版本改动到的行为、配置项或命令都要同步到官网文档避免发布后用户读到过时说明。这两步与后续第 8 步分享公告首尾呼应先写好内容最后再发布传播。第 3 步同步更新每个 Cargo.toml 的版本号Gleam 编译器是一个 Cargo workspace根目录 Cargo.toml 声明了 16 个成员 crate[workspace] resolver 2 members [ gleam-bin, compiler-cli, compiler-core, compiler-wasm, language-server, test-helpers-rs, test-commands, test-output, test-package-compiler, test-project-compiler, hexpm, pretty-arena, format, erlang-term-format, erlang-generation, src-span, ]发布时需要把这些成员 crate 的[package] version统一升到新版本号。以当前仓库为例gleam-bin/Cargo.toml 中version 1.18.0且 compiler-cli、compiler-core、language-server、hexpm、compiler-wasm、format 等成员的版本号也全部是1.18.0——版本号一旦不同步发布构建时依赖解析就可能出现版本混乱。这一步骤是后续 CI 生成安装包文件名gleam-版本-目标平台.tar.gz的依据。第 4 步本地跑通 make test build版本号统一后发布者要在本地执行完整验证。仓库根目录 Makefile 定义了这些目标make build执行cargo build --release产出 release 版编译器。make test执行完整的编译器单测与集成测试链包括cargo test --quiet、cargo clippy以及test/language、test/javascript_prelude、test/project_erlang、test/project_javascript、test/project_deno、test/hextarball、test/typescript_declarations、test/running_modules、test/subdir_ffi等端到端项目测试。test目标实际覆盖了从 Erlang/JavaScript/Deno 目标代码生成到 TS 声明、子目录 FFI、hex tarball 导出的方方面面。清单中的make test build相当于把上面两步串起来先保证全量测试通过make test再确认 release 构建成功make build。发布者还可以用make help查看所有目标及说明或用make test-watch基于watchexec的文件变更监听在迭代阶段快速回归。第 5 步Git 提交、打标签并推送本地验证通过后进入 Git 操作git add -A git commit -m Release v1.18.0 git tag v1.18.0 git push git push --tags标签名必须以v开头如v1.18.0因为 .github/workflows/release.yaml 的触发条件正是on: push: tags: - v*也就是说推送v*标签是启动整条 CI 发布流水线的唯一开关。从源码结构看标签命名还约定了一种特殊情况若标签包含-rc如v1.18.0-rc1CI 创建 Release 时会自动加上--prerelease标记作为预发布版本处理。第 6 步等待 CI 发布构建推送标签后release.yaml 会在 GitHub Actions 上启动build-release作业构建矩阵覆盖目标平台运行环境构建工具x86_64-unknown-linux-muslubuntu-latestcrossaarch64-unknown-linux-muslubuntu-latestcrossx86_64-apple-darwinmacos-15-intelcargoaarch64-apple-darwinmacos-latestcargox86_64-pc-windows-msvcwindows-2022cargoaarch64-pc-windows-msvcwindows-11-armcargowasm32-unknown-unknownubuntu-latestwasm-pack具体构建逻辑封装在 .github/actions/build-release/action.yml 这个复合 Action 中发布者等待期间可以理解 CI 在做什么构建与打包非 WASM 目标通过cross或cargo执行cargo build --release --target 目标产物命名为gleam-版本-目标.tar.gzWindows 为.zipWASM 目标用wasm-pack build --release --target web compiler-wasm产出gleam-版本-browser.tar.gz。产物校验用file命令核对二进制架构与期望一致并实际解包运行./gleam --version确认能正常启动。Windows 代码签名通过 Azure Trusted Signing 对gleam.exe进行 SHA256 签名并打 RFC3161 时间戳。安全与合规产物每个归档附带.sha256、.sha512校验和用cargo-sbom生成 SPDX 与 CycloneDX 两种格式的 SBOM通过actions/attest生成 SLSA 供应链证明.sigstore文件。许可证清单Linux musl 构建还会在licence-bundler目录下运行gleam run生成随 Release 附带的gleam-licences.html。从 .github/workflows/release.yaml 的RUSTFLAGS: -D warnings环境变量可以看出发布构建对代码质量要求严格——任何警告都会直接导致构建失败。第 7 步从 CI 草稿发布正式 Release当build-release作业在所有平台上成功后create-release作业needs: [build-release]会汇总下载所有release-*构建产物并执行gh release create \ --repo $REPOSITORY \ --title $TITLE \ --notes $NOTES \ --draft \ --verify-tag \ ${{ contains(github.ref_name, -rc) --prerelease || }} \ $TAG_NAME \ gleam-*关键点解读--draftCI 只会创建一个草稿 Release不会直接公开。这正是清单第 6、7 步之间人工确认的意义——发布者需要等所有平台的产物齐全、检查附件无误后再手动点击发布。--verify-tag确保待发布的标签真实存在。--notesRelease 说明直接链接到该版本标签下的 CHANGELOG.md因此第 4 步之前务必确认 CHANGELOG 已更新到位。-rc标签自动带--prerelease标记便于先发候选版本收集反馈。发布者此时只做一件事登录 GitHub打开 CI 生成的草稿核对版本号、CHANGELOG 链接与gleam-*附件归档、校验和、sigstore、SBOM、licences HTML后点击正式发布。第 8 步分享发布公告Release 正式发布后回到第 1 步写好的官网公告通过社区渠道对外分享并引导用户下载新版本。至此一个版本的生命周期闭环完成。附加环节容器镜像与每日夜间构建正式 Release 发布published事件还会触发 .github/workflows/release-containers.yaml基于 containers/ 目录中的 Dockerfile 矩阵构建并推送镜像基础镜像覆盖scratch、erlang、erlang-slim、erlang-alpine、elixir、elixir-slim、elixir-alpine、node、node-slim、node-alpine十种组合。此外仓库还维护一条不依赖正式发版的夜间通道.github/workflows/release-nightly.yaml 每天通过 cron45 0 * * *或手动触发先用 bin/add-nightly-suffix-to-versions.sh 给版本号追加 nightly 后缀再构建并更新名为Nightly的预发布版本——这条通道与正式发布相互独立正式发布流程中无需干预。发布清单速查表步骤关键操作仓库依据1撰写官网发布公告CHANGELOG.md、changelog/2更新官网文档language server、gleam.toml 等language-server/src、compiler-core/src/config.rs3同步所有Cargo.toml版本号Cargo.tomlworkspace 成员、gleam-bin/Cargo.toml4make test buildMakefile5commit、tagv*、push、push tags.github/workflows/release.yaml 触发条件6等待 CI 构建多平台产物 签名 SBOM.github/actions/build-release/action.yml7从草稿发布 Releasegh release create --draft --verify-tag.github/workflows/release.yamlcreate-release作业8分享官网发布公告—小结Gleam 的发布流程将文档先行、版本同步、本地全量验证、Git 标签触发、CI 自动构建、人工最终确认六个环节拆解得清晰可执行。对维护者而言日常只需关注清单前 5 步的人肉操作剩下的构建、签名、校验和、SBOM 与草稿生成全部由 .github/workflows/ 与 .github/actions/ 中的流水线自动完成对想借鉴发布经验的开发者而言这套草稿制发布 供应链安全产物 容器镜像矩阵的组合也是一个可以直接参考的 Rust 项目发版范本。【免费下载链接】gleam⭐️ A friendly language for building type-safe, scalable systems!项目地址: https://gitcode.com/GitHub_Trending/gl/gleam创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考