WeKan 发布工程全解从 releases/README.md 四步发布流程到多架构产物分发【免费下载链接】wekanThe Open Source kanban, built with Meteor. GitHub issues/PRs are only for FLOSS Developers, not for support, support is at https://wekan.fi/commercial-support/ . PR source translation to imports/i18n/data/en.i18n.json, other translations at https://app.transifex.com/wekan/wekan项目地址: https://gitcode.com/GitHub_Trending/we/wekan本文基于 WeKan 仓库中的 releases/README.md 展开逐段还原官方四步发布流程本地 x64 打包、远端多架构构建、产物归集、下载服务器发布并结合 releases/release.sh、releases/version.sh、releases/up.sh、releases/release-x2.sh 等实际脚本说明每一步背后的版本号同步、依赖探测与完整性校验机制读完你可以完整复现一次 WeKan 多平台版本的发布并理解其配套的安全网设计。发布流程总览四步走完一个版本releases/README.md 以版本 4.94 为例描述了 WeKan 一次完整发布的四个阶段构建 x64 bundle 并上传到下载服务器x2及构建服务器a/s/o./release.sh 4.94在远端构建服务器上分别构建 arm64、s390x、openpower bundlessh a后执行./maintainer-make-release-a.sh 4.94s390x 与 openpower 同理maintainer-make-release-s.sh、maintainer-make-release-o.sh从构建服务器下载各架构 bundle并统一上传到x2发布目录./releases/up.sh登录x2在/var/snap/wekan/common下执行./release-x2.sh 4.93 4.94完成下载站点的最终切换其中x2是 WeKan 的下载服务器对应 releases.wekan.teama、s、o是三台按 CPU 架构划分的构建服务器。原文还指向了 wekan-snap 仓库的“从源码制作 release”与 wekan-maintainer 仓库的 Sandstorm 构建两篇 wiki 文档分别覆盖 Snap 包与 Sandstorm 包的延伸发布路径。需要注意的是README 记录的是较早期的流程快照当前仓库中的 releases/release.sh 已改为必须传入“旧版本 新版本”两个参数./release.sh 9.16 9.17openpowerppc64le构建线也已在脚本中被注释停用。下文的源码解析均以当前仓库实际内容为准README 的四步骨架依然成立。第一步本地构建 x64 bundle 并固定版本号release.sh 的调用链当前 releases/release.sh 在通过参数校验后按固定顺序串联了发布的第一阶段工作releases/rebuild-docs.sh $2重建 API 文档public/api/wekan.html、public/api/wekan.yml的来源releases/version.sh $1 $2同步升级 WeKan 版本与 Node.js / MongoDB 依赖版本详见下文releases/release-bundle.sh $2真正执行 Meteor 构建并产出wekan-版本-amd64.zipgit add --all git commit -m v$2 git push把构建过程中产生的工件如package-lock.json一并提交releases/add-tag.sh v$2打版本标签并推送releases/release-website.sh $1 $2更新 wekan.fi 网站的版本号与 API 文档构建入口 releases/release-bundle.sh 的逻辑很直接cd ~/repos/wekan后执行 releases/rebuild-release.sh把.build目录下的产物zip -r wekan-$1-amd64.zip bundle再移动到DOWNLOAD_DIR默认$HOME/LatauksetLataukset是芬兰语“下载”的意思。构建完成后若 zip 不存在release.sh会直接报错退出这是防止“空发布”的第一道闸。releases/rebuild-release.sh 体现了构建机的环境自愈通过ensure-tools.sh按发行版安装npm、zip、meteormacOS 走 HomebrewLinux 走系统包管理器随后清理node_modules、.meteor/local、.build再执行meteor build .build --directory完成全新构建。脚本还特意提示若系统 locale 不是en_US.UTF-8需要额外安装该 locale并给出 Fedora/Debian/Arch/Alpine 各自的操作提示否则构建可能出现字符集问题。version.sh一次 bump多处同步releases/version.sh 是整个发布流水线中改动面最广的脚本它做三类事1探测并锁定依赖版本。在线模式下它抓取nodejs.org/dist/latest-v24.x/目录解析出最新的 Node.js 24.xWeKan 固定使用 Node.js 24 主线并且强制要求该版本的 linux-arm64 产物同时存在http_ok校验避免“amd64 有、arm64 没有”的版本被写进构建脚本MongoDB 侧则从 snapcraft.yaml 读出当前 7.x 版本在fastdl.mongodb.org上向前探测最多 3 个 minor、80 个 patch找到 amd64 与 arm64 双平台同时可用的最高版本。离线模式USE_LOCAL_DEP_VERSIONS1则跳过网络探测直接从DOWNLOAD_DIR本地缓存中解析已下载的node-v*-linux-*.tar.xz与mongodb-*.tgz文件名来确定版本——release.sh开头正是根据DOWNLOAD_DIR里是否已有这两类缓存文件来决定是否交互询问“是否检查网上最新版本”。2同步 WeKan 应用版本号到所有发布关键文件。脚本对 8 处版本载体逐一改写且几乎每一处都有“写后断言”失败即exit 1中止发布文件写入内容package.json / package-lock.jsonv版本.0两位版本号自动补第三位lock 文件顶层与packages[].version两处都要改注释说明了原因CI 直接提交version.sh产物中间没有npm install重新同步 lock 的机会Stackerfile.ymlappVersion: v版本.0snapcraft.yaml第 2 行version:、bundle 下载名wekan-版本-、releases/download/v版本/URL 三类引用sandstorm-pkgdef.capnpappVersion 去掉点的数字如 9160与appMarketingVersion v版本~YYYY-MM-DDDockerfileARG VERSION版本与METEOR_RELEASEMETEOR...从 .meteor/release 同步保证运行时元数据与真实构建框架一致docs/Platforms/Propietary/OS/Windows/Offline.mdWindows 离线安装文档中的下载链接失配仅告警不阻断发布值得强调的是这些 sed 锚点的设计哲学注释里写明“锚定字段名而不是旧值”self-healing anchors——例如 Dockerfile 的^ARG VERSION前缀匹配意味着即使上次的版本号残留成了“错误值”这次也会被强制归位而 WeKan 版本以v开头、依赖版本是裸 semver因此只匹配version: v[0-9]...就能精确避开 Node/MongoDB 的版本号绝不误伤依赖。3更新 Node.js / MongoDB 依赖引用。update_releases_node_versions只改写releases/下明确包含 Node 发布路径锚点nodejs.org/dist/v、node-v...-linux-、npm-node-version:、NODE_TAR的文件把任意旧的 24.x 升到新 24.x且“绝不改写其他 major”update_releases_mongo_versions同理只管理 MongoDB 7 servermongod的 ubuntu2204 归档名。mongosh 与 MongoDB Database Tools 不再做版本钉扎——WeKan 使用自带的 Node.js mongodb驱动Database Tools 取自 wekan/mongo-tools-patches 的最新 release注释与 releases/test-download-urls.sh 的头部说明一致。此外version.sh在无参运行时会从 CHANGELOG.md 的前两条# vNN.MM YYYY-MM-DD标题自动推断新旧版本并顺带下载依赖缓存、在本地检出.tools/wekan.fi与../w/charts/wekan时联动更新官网与 Helm chartrelease-charts.shGitHub Actions 场景下用RELEASE_SKIP_DEP_DOWNLOAD1跳过本地下载。第二步构建服务器上的多架构构建README 的第二步对应aarm64、ss390x、oopenpower三台构建服务器分别运行maintainer-make-release-{a,s,o}.sh 版本。这些脚本不在本仓库内属于维护者侧构建环境但它们与releases/目录中的脚本是配套关系release-bundle.sh中被注释的scp ... a: s: o:块见 releases/release-bundle.sh 第 20–29 行就是当年把 amd64 bundle 与各架构构建脚本分发到构建服务器、再回传产物的并行通道可从中读出历史拓扑arm64 产物落在a:/home/wekan/wekan-版本-arm64.zips390x 产物落在s:/home/linux1/wekan-版本-s390x.zipopenpower 产物落在o:/home/ubuntu/wekan-版本.zip当前仓库中这条 openpower 线已经退役releases/release-x2.sh 第 40 行明确注释“OpenPower MiniCloud is discontinued, no ppc64le build server”releases/up.sh 中up-o.sh一行也被注释掉。因此实际有效的远端构建矩阵是amd64本地 arm64 s390xWindows 包则由独立流程产出wekan-版本-amd64-windows.zip见up-w.sh从../../Julkinen/目录上传见下文。第三步产物归集——up.sh 与并行 scpreleases/up.sh 负责 README 第三步“下载 bundles 并上传到 x2 releases”{ ~/repos/wekan/releases/up-a.sh $1 ~/repos/wekan/releases/up-s.sh $1 #~/repos/wekan/releases/up-o.sh $1 ~/repos/wekan/releases/up-w.sh $1 } | parallel -k脚本开头有两处工程细节若运行在 zsh 下会exec /bin/bash重新以 bash 执行自身保证BASH_SOURCE可用通过ensure_tools parallel按平台包管理器确保 GNU parallel 已安装。随后用parallel -k把三个上传任务并行化。各子脚本的模式完全一致——先从构建服务器scp拉到本地再scp到下载服务器的对应架构目录脚本拉取源上传目标x2releases/up-a.sha:/home/wekan/wekan-v-arm64.zip/data/websites/releases.wekan.team/raspi3/releases/up-s.shs:/home/linux1/wekan-v-s390x.zip/data/websites/releases.wekan.team/s390x/releases/up-w.sh../../Julkinen/wekan-v-amd64-windows.zip/data/websites/releases.wekan.team/windows/也就是说下载服务器x2上按架构组织了目录根目录放 Linux x64raspi3/放 arm64沿用历史命名s390x/放 IBM z 架构windows/放 Windows 包——这一目录布局正是第四步release-x2.sh的操作舞台。第四步下载服务器上的最终切换release-x2.shreleases/release-x2.sh 接收“旧版本 新版本”两个参数对四个平台目录依次执行同一套动作把旧版本 zipmv进old-releases/归档目录把新版本复制为固定名字的 latest 文件最后对目录内所有 zip 重新生成SHA256SUMS.txtx64/data/websites/releases.wekan.team归档wekan-旧.zip与wekan-旧-amd64.zip然后cp wekan-新-amd64.zip wekan-latest-amd64.zip并保留wekan-新.zipWindowswindows/归档旧 Windows 包复制出wekan-latest-amd64-windows.ziparm64raspi3/归档后复制出wekan-latest-arm64.zips390xs390x/归档后复制出wekan-latest-s390x.zipppc64le整段已注释OpenPower MiniCloud 停用每个目录独立执行sha256sum wekan-*.zip SHA256SUMS.txt因此每个架构目录都有自己的校验和清单用户可以下载 zip 后离线验签。从源码结构看这里用cp生成 latest 文件而非ln -s符号链接而仓库中另有一个遗留的符号链接方案 releases/release-ln.shln -s wekan-v.zip wekan-latest-arch.zip且仍包含 ppc64le 分支说明下载站早期采用软链切换、后来改为复制实体文件release-ln.sh属于尚未删除的历史脚本。发布安全网版本一致性、依赖可达性与远程发布路径README 的四步之外releases/目录还沉淀了一整套让发布“失败得早、失败得响”的配套脚本理解它们才能真正把握 WeKan 的发布工程。verify-release-versions.mjs只读的版本一致性断言releases/verify-release-versions.mjs 是发布前/后的只读校验器传入期望版本可带v前缀它逐一核对 8 类版本载体是否与version.sh的产出一致——package.json根版本两位版本号按vX.Y.0归一、package-lock.json的顶层与packages[].version两处、Dockerfile的ARG VERSION、Stackerfile.yml的appVersion、snapcraft.yaml的version与全部wekan-/releases/download/vbundle 引用、sandstorm-pkgdef.capnp的数字appVersion与 marketing 版本并额外校验.meteor/release是合法 semver 且Dockerfile的METEOR_RELEASE与它同步。任何不一致都会以::error::release version mismatch: ...格式输出并以退出码 1 失败——脚本注释明确其意图“在提交或发布前让发布失败当 version.sh 遗漏了某个发布关键消费者时”。WEKAN_VERSION_ROOT环境变量可将校验指向任意检出目录便于在 CI 中对构建产物做复检。test-download-urls.sh依赖下载 URL 的 HEAD 巡检releases/test-download-urls.sh 用curl -I逐一探测 snapcraft.yaml 构建时依赖的下载 URL 是否可达头部注释同时给出了 Snap 各架构的打包策略是很好的“架构覆盖”权威说明amd64 / arm64原生 MongoDB 7 servermongo-tools 与 FerretDB 取自 wekan 分叉的最新 release覆盖全部架构armhf / s390x / ppc64elMongoDB 社区版没有这些架构的预编译包改为通过qemu-x86_64-static运行 amd64 二进制CPU 缺少 MongoDB 所需指令集如 AVX时同样自动回落到 QEMUNode.js 24 没有 linux-armv7l 产物故 armhf 不检查 Node URL基础镜像Snap 用 core24Ubuntu 24.04 LTSDocker 用 ubuntu:24.04它对 Node.js 24x64/arm64/s390x/ppc64le、MongoDB 7ubuntu2204 的 x86_64 与 aarch64、mongo-tools-patches 与 FerretDBamd64/arm64/s390x/ppc64le/riscv64 五架构逐个做 HTTP 状态码检查任何一个 404 都会以退出码 1 终止并提示“先更新 snapcraft.yaml 再发布”。release-all.sh一键触发的远程发布路径除 README 描述的本地四步外当前仓库还提供了一条全远程发布路径releases/release-all.sh本地只做四件小事——用 releases/fix-changelog-hashes.sh 修正 CHANGELOG 条目中因 rebase/squash 失效的 commit 链接、从 CHANGELOG.md 自动推断新旧版本若存在# Upcoming WeKan ® release段则将其重命名为“上一个版本 1 minor、日期为今天”强制 1 递增并在检测到版本号跳变时报错避免漏发号段被固化为习惯、提交并推送待发布改动、gh workflow run release-all.yml -f old_version... -f new_version...触发 GitHub Actions。后续的重活全部在远端并行完成bumpversion.shrebuild-docs.sh、wekan.fi 官网更新、Helm chart 发布、多架构 bundle / Docker 镜像 / snap 构建。所需 secretsDOCKERHUB_AUTH、QUAY_AUTH、GHCR_AUTH、SNAP_AUTH、LP_CREDENTIALS、WEKAN_REPO_TOKEN可由 releases/create-github-secrets.sh 创建。版本号处理上有个精巧的细节wekan_enc/wekan_dec把NN.MM编码成整数NN*100MM使 minor 99 进位到下一个 major9.99 → 10.00成为一次纯整数运算。snap 通道的批量发布产物进入 Snap 商店由 releases/snap-release-all-channels.sh 统一完成。脚本头部注释值得完整一读WeKan 发布3 个 snapwekan、wekan-ondra、wekan-gantt-gpl×6 个 Snap 架构×4 个通道edge、beta、candidate、stable共 72 个“snap架构通道”组合早期一行snapcraft release wekan $1 edge,beta,candidate的写法在三个维度上都是错的只发了一个 snap、revision 是按架构各自的却只传一个号、漏掉 stable 通道。新脚本从商店 API 按snap架构解析 revision保证同一 revision 要么四个通道全达、要么全不达。它有意只覆盖 6 而非 8 个 bundle 架构core24 没有 i386 移植build-on: i386直接是解析错误会拖垮全部架构的构建i386 由 .deb/AppImage 供给而 armv7 指的是 ODroid-U3与 Snap 商店里 32 位树莓派的armhf是不同 CPU不能混发。另一处易错点也在这里收口bundle 用 Node.js/内核的命名ppc64leSnap 商店用 Debian 命名ppc64el二者映射集中放在 models/lib/snapArchitectures.js脚本通过node -e require(...)读取该单一事实源而不是在 bash 里维护第二份表--dry-run、--snap、--arch选项则支持预览与单点操作。发布前的单架构构建可用 releases/release-snap.sh 本地完成rebuild-release.sh→snapcraft→snapcraft push多架构与商店同步则由 GitHub Actions 承担。复现与验证清单如果你要在本地完整演练一遍发布逻辑仅演练不做真实发布可按如下顺序核对阅读 CHANGELOG.md 的最新两个# vNN.MM标题确认新旧版本对本地跑releases/rebuild-release.sh需要 Meteor 与en_US.UTF-8locale检查.build/bundle产物完整执行releases/verify-release-versions.mjs期望版本确认 8 处版本载体全部一致执行releases/test-download-urls.sh确认 snap 构建依赖的全部上游 URL 可达对照 releases/expected-assets.sh 与 releases/provenance-table.sh、releases/record-provenance.sh 等脚本了解产物清单与来源记录约定。此外tests/目录下存在大量针对发布链路的回归测试例如 tests/changelogEntriesBelongToTheirRelease.test.cjs校验 CHANGELOG 条目与发布版本的归属正是release-all.sh注释中提到的守卫、[tests/verify-release-versions 相关用例] 对应的版本一致性断言、tests/bundleTrim.test.cjs 与 tests/bundleSmokeBoot.test.cjsbundle 裁剪与冒烟启动、tests/changelogFormat.test.cjs 与 tests/changelogCommitLinks.test.cjschangelog 格式与 commit 链接它们在持续集成中为上述脚本的每次改动兜底。小结WeKan 的发布体系以 releases/README.md 的四步流程为骨架本地release.sh串起文档重建、版本 bump、bundle 构建、提交打标签与官网更新构建服务器按架构补齐 arm64/s390x 产物up.sh用 GNU parallel 并行归集到下载服务器release-x2.sh完成“归档旧版、固定 latest 文件名、重算 SHA256SUMS”的最终切换。在此之上version.sh的“字段锚定 写后断言”、verify-release-versions.mjs的多载体一致性校验、test-download-urls.sh的 URL 巡检与release-all.sh的 GitHub Actions 全远程路径共同构成了一套“版本号一处改动、处处一致任何失配尽早失败”的发布工程范式——对任何需要维护多架构、多包格式分发的项目这套设计都具有很高的参考价值。【免费下载链接】wekanThe Open Source kanban, built with Meteor. GitHub issues/PRs are only for FLOSS Developers, not for support, support is at https://wekan.fi/commercial-support/ . PR source translation to imports/i18n/data/en.i18n.json, other translations at https://app.transifex.com/wekan/wekan项目地址: https://gitcode.com/GitHub_Trending/we/wekan创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考