WeKan Snap core24 多架构构建QEMU 路径的 core22 上限与 Launchpad remote-build 迁移实录【免费下载链接】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 发行管线中 snap 多架构构建的一次真实事故为主线为什么基于core24基底的 snap 无法再用 QEMU 模拟方式为ppc64el、s390x构建为什么最终必须迁移到 Launchpadsnapcraft remote-build以及迁移后snap-launchpad任务为扛住远程队列做了哪些加固。读完你将掌握 snap 发行任务在原生 runner 缺失 snapcraft 不支持交叉构建约束下的唯一可行路径并能从源码层识别多架构 Action 的基底上限而非依赖报错文案。背景WeKan 的 snap 发布矩阵与core24基底WeKan 仓库根目录的 snapcraft.yaml 是发行管线实际使用的默认 snap 配置其关键声明为name: wekan base: core24 confinement: strict grade: stable compression: lzo选用core24不是随意的core24是已发布的正式基底snap 才能携带grade: stable从而被发布到全部四个通道stable、candidate、beta、edge。snapcraft-core26.yaml虽然同样是同一套 WeKanMeteor 3.5、Node.js 24、FerretDB v1、MongoDB 7、Caddy 2但因为 core26 仍是实验性基底必须使用build-base: devel从而强制grade: develdevel 级 snap 会被 stable 与 candidate 通道拒绝只能进入 beta 和 edge——这正是发行保持 core24 的全部原因。该文件通过platforms:键snapcraft 8 语法声明了全部架构amd64、arm64、s390x、ppc64el、riscv64、armhf其中s390x/ppc64el/riscv64/armhf是 FerretDB-only 架构MongoDB 不发布这些平台的服务端二进制。文件头注释还特别解释了不存在i386条目的原因core24Ubuntu 24.04没有 i386 移植且那是一个解析期错误会拖垮所有架构的构建。故障现场snap-qemu任务在读取基底前即告失败曾有一个snap-qemu任务用diddlesnaps/snapcraft-multiarch-actionv1在 QEMU 模拟下为ppc64el和s390x构建 snap。其最后一次运行的日志release-all.yml→snap-qemu矩阵腿如下snapcraft.yaml is at version 10.01. # version gate passed Building Snapcraft project in .... ##[error]Your build requires a base that this tool does not support (core24). base or build-base in your snapcraft.yaml must be one of core, core18 or core20.要点在于版本检查通过了、QEMU 也正常就绪构建是在 snapcraft 读到base: core24的瞬间死掉的。日志中还有两行容易误导人的无害噪声Failed to save: Unable to reserve cache with key docker.io--tonistiigi--binfmt-...—— 来自 QEMU binfmt 镜像的后置缓存告警不是失败原因Node.js 20 is deprecated ...—— 旧 Action 跑在更新的 Node 运行时上同样无关。根因从 Action 源码验证的硬编码基底白名单这不仅仅是一条报错信息而是一份写死在代码里的允许列表。diddlesnaps/snapcraft-multiarch-action被固定pin在提交 SHAcfd7a246fad6bea65bb92f69a1c8d07898c231e5其编译产物dist/index.js由src/lib/build.js与src/lib/channel-matrix.js构成在三处独立位置硬编码了最大基底为core221. 直接抛错的允许列表build.jsconst base await detectBase(this.projectRoot); if (![core, core18, core20, core22].includes(base)) { throw new Error(Your build requires a base that this tool does not support (${base}). ...); }core24不在列表中于是立刻抛出。有趣的是报错文案本身已过时——它说must be one of core/core18/core20而代码实际还允许core22。2. 容器镜像标签build.jslet containerImage diddledani/snapcraft:${base}; // needs docker.io/diddledani/snapcraft:core24它在 QEMU 下运行docker.io/diddledani/snapcraft:base中的 snapcraft。维护者从未发布过:core24标签——镜像标签止步于core22。3. 通道矩阵channel-matrix.jsswitch (base) { case core22: case core20: return channel; case core18: ... case core: ... } throw new Error(Snapcraft Channel ${channel} is unsupported ... ${base} Base Snap.);getChannel(core24, stable)会穿过所有 case 走到最后一行同样抛出。结论明确diddlesnaps/snapcraft-multiarch-actionv1支持的最大基底是core22。该 Action 在上一次更新到core22后即被弃用core24以及未来的core26不会被v1支持。目前也不存在维护中的、支持core24的 QEMU 多架构 snap Action。关键约束为什么非原生架构必须换路约束说明amd64/arm64有 GitHub 原生 runnersnapcore/action-build直接原生构建最快ppc64el/s390x/riscv64没有 GitHub 原生 runnersnapcraft不能交叉构建 snap没有原生 runner加上不能交叉构建剩下两条路QEMU 模拟对core24不可行原因如上或 Launchpad 远程构建。这就是为什么 release-all.yml 中snap-native snap-launchpad取代了旧的单一snap任务主流架构原生构建异形架构全部走 Launchpad——这是它们在core24基底上的唯一受支持机制。修复方案迁移到 Launchpadremote-build并强化任务由于没有任何 QEMU 多架构 Action 支持core24ppc64el与s390x无法继续留在snap-qemu中。修复已完成这两个架构移入snap-launchpad矩阵与riscv64一同构建snap-qemu任务被删除。文档记录当时的矩阵为arch: [ppc64el, s390x, riscv64]截至当前仓库snap-launchpad 的矩阵 已演进为arch: [ppc64el, s390x, riscv64, armhf]armhf 后加入i386 因 core24 无移植而刻意缺席。当前发行管线中 snap 任务的划分源自 release-all.yml 注释与定义任务架构机制支持core24snap-nativeamd64、arm64snapcore/action-build原生 runner是snap-launchpadppc64el、s390x、riscv64、armhfsnapcraft remote-buildLaunchpad是snap-qemu已删除ppc64el、s390xQEMU 下的diddlesnaps/snapcraft-multiarch-action否封顶core22新snap-launchpad任务比它取代的旧 Launchpad 腿更健壮以下几处加固可以在 release-all.yml 中逐条找到要求.snap文件真实存在remote-build可能在未产出.snap的情况下以 0 退出只下载了日志因此任务用shopt -s nullglob的真实通配符收集产物并用snap_ok()校验文件存在、大小不低于 50 MB最小 WeKan snap 是数百 MB低于此值即截断下载或错误页、前四个字节为 squashfs 魔数hsqs。历史教训是 v10.48 曾用字面量文件名数组 长度判断该字符串不含通配符、永远为真导致把不存在的文件上传到 Snap Store报出wekan_10.48_s390x.snap is not a valid filesnapcraft upload退出码 64。远程构建重试 3 次每次重试前清空~/.cache/snapcraft/remote-build避免复用半推送的克隆只有文件校验通过才上传。continue-on-error: truetimeout-minutes: 360fail-fast: falseLaunchpad 队列可能长达数小时这是该路径的代价既不能让某个异形架构拖红整个发行也不能让一个架构取消其他架构每个架构完成后立即各自发布。针对 riscv64 队列超过 GitHub 六小时任务上限的历史问题任务用timeout 300m snapcraft remote-build不带--foreground否则终止行为会变成 The operation was canceled只结束本地等待Launchpad 上已命名的构建继续运行重跑时借助确定性的单提交快照重新连接并下载产物。历史铺平flatten historyremote-build会把项目 git 仓库推送到git.launchpad.net并拒绝浅克隆但 WeKan 的完整历史过大推送会超时Could not push HEAD ... ~4-5 分钟。任务在完整检出后git init重新初始化为带原提交时间戳的单提交完整仓库既满足非浅克隆要求又让推送只有源码树大小版本取自snapcraft.yaml构建前会校验其version:与发布 tag 一致与 git-describe 无关因此丢弃历史不影响产物。凭据按名检查首个步骤同时检查SNAP_AUTH与LP_CREDENTIALS缺失时按名报错LP_CREDENTIALS会被 base64 解码验证base64 -w0 ~/.local/share/snapcraft/launchpad-credentials不可用的值会成为一行具名错误而非普通构建失败。构建失败时还会先做确定性失败判定如Stage package not foundUbuntu 24.04 的 64 位time_t过渡把库改名为 t64 后缀Provides:在 armhf 上不成立需在snapcraft.yaml中写真实包名如libssl3t64、libcurl4t64再检查 Launchpad 授权失败模式最后才归因于临时性 OOM。任务还依赖发布流程全局的snap-auth-checkrelease-all.yml用snapcraft whoami在构建开始前就从 Snap Store 端验证SNAP_AUTH是否可用区分无法解析粘贴了终端输出而非文件内容已过期导出的登录默认一年有效未覆盖 snap 名称需 ACL 覆盖wekan、wekan-ondra、wekan-gantt-gpl三个名字或packages: no restrictions三种失败。凭据配置SNAP_AUTH 与 LP_CREDENTIALSsnap-launchpad需要两个仓库 Secret。仓库内的 releases/create-github-secrets.sh 记录了标准生成流程SNAP_AUTHSnap Store 凭据直接作为SNAPCRAFT_STORE_CREDENTIALS使用不 base64sudo snap install snapcraft --classic snapcraft login # 登录拥有 wekan 的 Snap Store 账号 snapcraft export-login --snapswekan \ --aclspackage_access,package_push,package_update,package_release \ --channelsedge,beta snap-store-credentials.txt # 取整个文件内容作为 SNAP_AUTHLP_CREDENTIALSLaunchpad 远程构建凭据的 base64# 首次在带浏览器的机器上授权一次会写入 ~/.local/share/snapcraft/launchpad-credentials snapcraft remote-build --launchpad-accept-public-upload # 生成 Secret 值 base64 -w0 ~/.local/share/snapcraft/launchpad-credentials工作流对凭据做了两层防御snap-auth-check用snapcraft whoami预先问询 Snap Store而每个使用凭据的任务snap-native、snap-launchpad、snap-variants把缺失/损坏/过期/权限不足四种情况分别命名为日志中的具名错误行而不是留下一串裸的 401/403。历史注记从 Launchpad 到 QEMU再回到 Launchpadppc64el/s390x曾被从Launchpad 迁到QEMU因为旧 Launchpad 腿以 Stopped 状态结束无 snap 产物随后在snapcraft upload处失败。而这条逃生路线如今对core24是死路Action 封顶core22且加固后的snap-launchpad任务恰好解决了当初促成迁移的上传失败is not a valid file。此外Launchpad 上自动生成的远程构建项目xet7-craft-remote-build需要设置许可证WeKan 的 MIT/X/Expat否则免费托管的构建会被 Launchpad 自行停止——这也是 v10.48 的教训之一。若未来想回到 QEMU 式多架构构建前提是存在一个维护中的 Action/镜像内置支持core24的 snapcraft8.x且为每个目标架构提供配套的core24构建容器。截至本文写作时尚不存在可即插即用的方案Canonical 对core24上非原生架构的官方答案是 Launchpadremote-build。相关文件速查docs/Design/Autoupdate/Forks/Snap-Core.md —— 本文依据的开发者笔记原文snapcraft.yaml —— 默认 core24 基底、platforms:六架构声明snapcraft-core26.yaml —— core26 实验变体build-base: devel、grade: devel.github/workflows/release-all.yml ——snap-auth-check、snap-native、snap-launchpad任务定义与加固逻辑releases/create-github-secrets.sh ——SNAP_AUTH/LP_CREDENTIALS生成指引【免费下载链接】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），仅供参考 WeKan Snap core24 多架构构建：QEMU 路径的 core22 上限与 Launchpad remote-build 迁移实录
WeKan Snap core24 多架构构建QEMU 路径的 core22 上限与 Launchpad remote-build 迁移实录【免费下载链接】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 发行管线中 snap 多架构构建的一次真实事故为主线为什么基于core24基底的 snap 无法再用 QEMU 模拟方式为ppc64el、s390x构建为什么最终必须迁移到 Launchpadsnapcraft remote-build以及迁移后snap-launchpad任务为扛住远程队列做了哪些加固。读完你将掌握 snap 发行任务在原生 runner 缺失 snapcraft 不支持交叉构建约束下的唯一可行路径并能从源码层识别多架构 Action 的基底上限而非依赖报错文案。背景WeKan 的 snap 发布矩阵与core24基底WeKan 仓库根目录的 snapcraft.yaml 是发行管线实际使用的默认 snap 配置其关键声明为name: wekan base: core24 confinement: strict grade: stable compression: lzo选用core24不是随意的core24是已发布的正式基底snap 才能携带grade: stable从而被发布到全部四个通道stable、candidate、beta、edge。snapcraft-core26.yaml虽然同样是同一套 WeKanMeteor 3.5、Node.js 24、FerretDB v1、MongoDB 7、Caddy 2但因为 core26 仍是实验性基底必须使用build-base: devel从而强制grade: develdevel 级 snap 会被 stable 与 candidate 通道拒绝只能进入 beta 和 edge——这正是发行保持 core24 的全部原因。该文件通过platforms:键snapcraft 8 语法声明了全部架构amd64、arm64、s390x、ppc64el、riscv64、armhf其中s390x/ppc64el/riscv64/armhf是 FerretDB-only 架构MongoDB 不发布这些平台的服务端二进制。文件头注释还特别解释了不存在i386条目的原因core24Ubuntu 24.04没有 i386 移植且那是一个解析期错误会拖垮所有架构的构建。故障现场snap-qemu任务在读取基底前即告失败曾有一个snap-qemu任务用diddlesnaps/snapcraft-multiarch-actionv1在 QEMU 模拟下为ppc64el和s390x构建 snap。其最后一次运行的日志release-all.yml→snap-qemu矩阵腿如下snapcraft.yaml is at version 10.01. # version gate passed Building Snapcraft project in .... ##[error]Your build requires a base that this tool does not support (core24). base or build-base in your snapcraft.yaml must be one of core, core18 or core20.要点在于版本检查通过了、QEMU 也正常就绪构建是在 snapcraft 读到base: core24的瞬间死掉的。日志中还有两行容易误导人的无害噪声Failed to save: Unable to reserve cache with key docker.io--tonistiigi--binfmt-...—— 来自 QEMU binfmt 镜像的后置缓存告警不是失败原因Node.js 20 is deprecated ...—— 旧 Action 跑在更新的 Node 运行时上同样无关。根因从 Action 源码验证的硬编码基底白名单这不仅仅是一条报错信息而是一份写死在代码里的允许列表。diddlesnaps/snapcraft-multiarch-action被固定pin在提交 SHAcfd7a246fad6bea65bb92f69a1c8d07898c231e5其编译产物dist/index.js由src/lib/build.js与src/lib/channel-matrix.js构成在三处独立位置硬编码了最大基底为core221. 直接抛错的允许列表build.jsconst base await detectBase(this.projectRoot); if (![core, core18, core20, core22].includes(base)) { throw new Error(Your build requires a base that this tool does not support (${base}). ...); }core24不在列表中于是立刻抛出。有趣的是报错文案本身已过时——它说must be one of core/core18/core20而代码实际还允许core22。2. 容器镜像标签build.jslet containerImage diddledani/snapcraft:${base}; // needs docker.io/diddledani/snapcraft:core24它在 QEMU 下运行docker.io/diddledani/snapcraft:base中的 snapcraft。维护者从未发布过:core24标签——镜像标签止步于core22。3. 通道矩阵channel-matrix.jsswitch (base) { case core22: case core20: return channel; case core18: ... case core: ... } throw new Error(Snapcraft Channel ${channel} is unsupported ... ${base} Base Snap.);getChannel(core24, stable)会穿过所有 case 走到最后一行同样抛出。结论明确diddlesnaps/snapcraft-multiarch-actionv1支持的最大基底是core22。该 Action 在上一次更新到core22后即被弃用core24以及未来的core26不会被v1支持。目前也不存在维护中的、支持core24的 QEMU 多架构 snap Action。关键约束为什么非原生架构必须换路约束说明amd64/arm64有 GitHub 原生 runnersnapcore/action-build直接原生构建最快ppc64el/s390x/riscv64没有 GitHub 原生 runnersnapcraft不能交叉构建 snap没有原生 runner加上不能交叉构建剩下两条路QEMU 模拟对core24不可行原因如上或 Launchpad 远程构建。这就是为什么 release-all.yml 中snap-native snap-launchpad取代了旧的单一snap任务主流架构原生构建异形架构全部走 Launchpad——这是它们在core24基底上的唯一受支持机制。修复方案迁移到 Launchpadremote-build并强化任务由于没有任何 QEMU 多架构 Action 支持core24ppc64el与s390x无法继续留在snap-qemu中。修复已完成这两个架构移入snap-launchpad矩阵与riscv64一同构建snap-qemu任务被删除。文档记录当时的矩阵为arch: [ppc64el, s390x, riscv64]截至当前仓库snap-launchpad 的矩阵 已演进为arch: [ppc64el, s390x, riscv64, armhf]armhf 后加入i386 因 core24 无移植而刻意缺席。当前发行管线中 snap 任务的划分源自 release-all.yml 注释与定义任务架构机制支持core24snap-nativeamd64、arm64snapcore/action-build原生 runner是snap-launchpadppc64el、s390x、riscv64、armhfsnapcraft remote-buildLaunchpad是snap-qemu已删除ppc64el、s390xQEMU 下的diddlesnaps/snapcraft-multiarch-action否封顶core22新snap-launchpad任务比它取代的旧 Launchpad 腿更健壮以下几处加固可以在 release-all.yml 中逐条找到要求.snap文件真实存在remote-build可能在未产出.snap的情况下以 0 退出只下载了日志因此任务用shopt -s nullglob的真实通配符收集产物并用snap_ok()校验文件存在、大小不低于 50 MB最小 WeKan snap 是数百 MB低于此值即截断下载或错误页、前四个字节为 squashfs 魔数hsqs。历史教训是 v10.48 曾用字面量文件名数组 长度判断该字符串不含通配符、永远为真导致把不存在的文件上传到 Snap Store报出wekan_10.48_s390x.snap is not a valid filesnapcraft upload退出码 64。远程构建重试 3 次每次重试前清空~/.cache/snapcraft/remote-build避免复用半推送的克隆只有文件校验通过才上传。continue-on-error: truetimeout-minutes: 360fail-fast: falseLaunchpad 队列可能长达数小时这是该路径的代价既不能让某个异形架构拖红整个发行也不能让一个架构取消其他架构每个架构完成后立即各自发布。针对 riscv64 队列超过 GitHub 六小时任务上限的历史问题任务用timeout 300m snapcraft remote-build不带--foreground否则终止行为会变成 The operation was canceled只结束本地等待Launchpad 上已命名的构建继续运行重跑时借助确定性的单提交快照重新连接并下载产物。历史铺平flatten historyremote-build会把项目 git 仓库推送到git.launchpad.net并拒绝浅克隆但 WeKan 的完整历史过大推送会超时Could not push HEAD ... ~4-5 分钟。任务在完整检出后git init重新初始化为带原提交时间戳的单提交完整仓库既满足非浅克隆要求又让推送只有源码树大小版本取自snapcraft.yaml构建前会校验其version:与发布 tag 一致与 git-describe 无关因此丢弃历史不影响产物。凭据按名检查首个步骤同时检查SNAP_AUTH与LP_CREDENTIALS缺失时按名报错LP_CREDENTIALS会被 base64 解码验证base64 -w0 ~/.local/share/snapcraft/launchpad-credentials不可用的值会成为一行具名错误而非普通构建失败。构建失败时还会先做确定性失败判定如Stage package not foundUbuntu 24.04 的 64 位time_t过渡把库改名为 t64 后缀Provides:在 armhf 上不成立需在snapcraft.yaml中写真实包名如libssl3t64、libcurl4t64再检查 Launchpad 授权失败模式最后才归因于临时性 OOM。任务还依赖发布流程全局的snap-auth-checkrelease-all.yml用snapcraft whoami在构建开始前就从 Snap Store 端验证SNAP_AUTH是否可用区分无法解析粘贴了终端输出而非文件内容已过期导出的登录默认一年有效未覆盖 snap 名称需 ACL 覆盖wekan、wekan-ondra、wekan-gantt-gpl三个名字或packages: no restrictions三种失败。凭据配置SNAP_AUTH 与 LP_CREDENTIALSsnap-launchpad需要两个仓库 Secret。仓库内的 releases/create-github-secrets.sh 记录了标准生成流程SNAP_AUTHSnap Store 凭据直接作为SNAPCRAFT_STORE_CREDENTIALS使用不 base64sudo snap install snapcraft --classic snapcraft login # 登录拥有 wekan 的 Snap Store 账号 snapcraft export-login --snapswekan \ --aclspackage_access,package_push,package_update,package_release \ --channelsedge,beta snap-store-credentials.txt # 取整个文件内容作为 SNAP_AUTHLP_CREDENTIALSLaunchpad 远程构建凭据的 base64# 首次在带浏览器的机器上授权一次会写入 ~/.local/share/snapcraft/launchpad-credentials snapcraft remote-build --launchpad-accept-public-upload # 生成 Secret 值 base64 -w0 ~/.local/share/snapcraft/launchpad-credentials工作流对凭据做了两层防御snap-auth-check用snapcraft whoami预先问询 Snap Store而每个使用凭据的任务snap-native、snap-launchpad、snap-variants把缺失/损坏/过期/权限不足四种情况分别命名为日志中的具名错误行而不是留下一串裸的 401/403。历史注记从 Launchpad 到 QEMU再回到 Launchpadppc64el/s390x曾被从Launchpad 迁到QEMU因为旧 Launchpad 腿以 Stopped 状态结束无 snap 产物随后在snapcraft upload处失败。而这条逃生路线如今对core24是死路Action 封顶core22且加固后的snap-launchpad任务恰好解决了当初促成迁移的上传失败is not a valid file。此外Launchpad 上自动生成的远程构建项目xet7-craft-remote-build需要设置许可证WeKan 的 MIT/X/Expat否则免费托管的构建会被 Launchpad 自行停止——这也是 v10.48 的教训之一。若未来想回到 QEMU 式多架构构建前提是存在一个维护中的 Action/镜像内置支持core24的 snapcraft8.x且为每个目标架构提供配套的core24构建容器。截至本文写作时尚不存在可即插即用的方案Canonical 对core24上非原生架构的官方答案是 Launchpadremote-build。相关文件速查docs/Design/Autoupdate/Forks/Snap-Core.md —— 本文依据的开发者笔记原文snapcraft.yaml —— 默认 core24 基底、platforms:六架构声明snapcraft-core26.yaml —— core26 实验变体build-base: devel、grade: devel.github/workflows/release-all.yml ——snap-auth-check、snap-native、snap-launchpad任务定义与加固逻辑releases/create-github-secrets.sh ——SNAP_AUTH/LP_CREDENTIALS生成指引【免费下载链接】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），仅供参考