Mealie 维护者指南Issue 三态工作流与基于 GitHub Actions 的自动化发版全流程【免费下载链接】mealieMealie is a self hosted recipe manager and meal planner with a RestAPI backend and a reactive frontend application built in Vue for a pleasant user experience for the whole family. Easily add recipes into your database by providing the url and mealie will automatically import the relevant data or add a family recipe with the UI editor项目地址: https://gitcode.com/GitHub_Trending/me/mealieMealie自托管菜谱管理与膳食规划系统为仓库维护者沉淀了一套可落地的协作规范从 Issue 进入仓库时的bugtriage双标签到确认后归入bug:confirmed或needs more info两态再到“起草 GitHub Release 即完成镜像发布”的纯自动化发版链路。本文以 docs/docs/contributors/developers-guide/maintainers.md 为骨架结合仓库内的 GitHub Actions 工作流与 Issue 模板源码还原这套维护工作流的真实实现帮助你理解并复用 Mealie 的维护实践。谁适合阅读本文已受邀加入 Mealie GitHub 组织、希望承担维护职责的贡献者想深度参与 Mealie 开发者社区、承担 Issue 评审与发版职责的社区成员希望为自己的开源项目引入“自动化发版 规范化 Issue 治理”模式的仓库维护者。仓库根目录的 MAINTAINERS.md 只是入口仓库根目录的 MAINTAINERS.md 仅有一行跳转真正的维护者指南位于 docs/docs/contributors/developers-guide/maintainers.md与building-packages.md、code-contributions.md、database-changes.md、migration-guide.md、starting-dev-server.md等文档共同构成开发者指南位于 docs/docs/contributors/developers-guide。本文即基于该指南原文展开并用仓库源码验证其中的每一条流程。Managing IssuesIssue 的三态评审工作流入口bugtriage双标签当新 Issue 提交到仓库时会自动被打上bug和triage两个标签表示“这是一个待维护者评审、判断有效性的候选”。这套默认标签定义在 .github/ISSUE_TEMPLATE/bug-report.yaml 中name: Bug Report description: Submit a bug for the latest version of Mealie title: [BUG] - YOUR DESCRIPTIVE TITLE GOES HERE labels: [bug, triage]也就是说使用标准 Bug Report 模板提交的 Issue 从创建那一刻起就带上了评审标记维护者需要对其做有效性判断。评审后的一进二两种去向维护者评审一个 Issue 后它通常会进入以下两种状态之一状态含义后续动作bug:confirmed维护者成功复现了该问题确认需要修复进入修复队列等待 PR 修复needs more info原始报告信息不足无法确认问题等待报告者补充信息若报告者未补充Issue 会被自动关闭无论归入哪一种评审完成并重新分类后维护者都应移除triage标签表示该 Issue 已进入正式流转而非待评审状态。评审时的四条实操准则指南明确给出了处理 Issue 时应该遵循的原则允许忽略低质量 Issue——遇到低质量报告直接忽略完全合理对未按标准模板提交的 Issue 应关闭并请报告者使用正确模板重新提交不要尝试复现缺少清晰复现步骤、未提供版本号或描述含糊的 Issue非 Bug 类 Issue 应转为 Discussion在 .github/ISSUE_TEMPLATE/config.yml 中Feature Request 就通过 contact links 定向到 GitHub Discussions与 bug 通道彻底分流。标准模板要求报告者提供“复现步骤、相关日志、Mealie 版本、部署方式”这正是评审时判断信息是否充分的基础例如 bug-report.yaml 中validations.required强制要求填写复现步骤与日志并用 dropdown 收集 Docker/Unraid/TrueNAS 等部署环境让维护者能快速定位环境相关因素。自动化兜底90 天 stale 机制指南中“未补充信息将自动关闭”的兜底动作由 .github/workflows/stale.yml 实现每天定时cron30 1 * * *运行对 90 天无活动的 Issue/PR 打上stale标签但days-before-issue-close: -1意味着仅标记、不自动关闭。同时pinned、security、bug: confirmed、feedback、task等标签被豁免带里程碑的 Issue/PR 也全部豁免——这从源码层面印证了指南的“信息不足才关闭”原则自动流程负责提醒人工决策负责关闭。Drafting Releases从 GitHub Release 到 Docker 镜像的自动化发版Mealie 的发布体系完全构建在 GitHub Actions 之上因此“创建一个新 GitHub Release”就等于“发布一个新版本镜像”。镜像标签矩阵镜像标签发布时机触发工作流ghcr.io/mealie-recipes/mealie:nightly每次推送到mealie-next分支.github/workflows/nightly.ymlghcr.io/mealie-recipes/mealie:latest创建新的 GitHub Release.github/workflows/release.ymlghcr.io/mealie-recipes/mealie:{version}创建新的 GitHub Release.github/workflows/release.yml注意latest与{version}两个标签在发布新版本时指向同一份镜像。实际构建链路验证nightly 链路nightly.yml监听对mealie-next分支的 push并忽略*.md、.vscode/**、docs/**等纯文档变更依次运行后端测试、前端测试、构建 Python 包最后调用publish.yml以nightly标签构建并推送镜像完成后通过 Discord Webhook 通知DISCORD_NIGHTLY_WEBHOOK。release 链路release.yml监听release: published事件先由commit-version-bump作业自动从 tag 提取版本号sed s/^v//批量改写 pyproject.toml、uv.lock、frontend/package.json 以及三处安装文档中的版本字符串并提交提交者身份为mealie-commit-bot[bot]随后把 release tag 移到新提交上接下来并行执行后端/前端测试与打包全部通过后由publish作业构建并推送hkotel/mealie:latest与ghcr.io/...:latest。版本号来源指南强调“不要手动改代码里的版本号”。版本号由 release tag 在构建时注入publish.yml 通过docker/metadata-action覆盖org.opencontainers.image.version标签并以COMMITbuild-arg 传入 commit SHA实现了“代码零版本号、tag 即版本”的自动注入。失败自动回滚若publish失败release.yml的rollback-on-failure作业会删除 release tag、revert 版本号提交避免留下“tag 存在但镜像未发布”的脏状态。发布前通过DISCORD_RELEASE_WEBHOOK在 Discord 发布“版本已发布”通知与 nightly 通知形成完整的信息闭环。起草 Release 的四步流程进入 GitHub Release 页面点击Draft a new release选择 tag并按语义化版本SemVer递增major对应破坏性变更、minor对应新功能、patch对应 Bug 修复命名 Release通常直接用 tag 名即可若有值得突出的特性可以在名称中体现点击Generate release notes由 GitHub 自动把自上个 Release 以来的全部提交拉入变更日志。纯 Bug 修复型版本这已经足够若有重大特性或体验优化应在完整变更日志之前单独成段说明。Tags 与 Releases 的版本策略Mealie 严格遵循 Semver 策略力求版本稳定Major仅用于破坏性变更预期不会频繁出现短期内保持 v1.x.xMinor用于新功能更新频繁Patch用于 Bug 修复更新频繁。任何具备 Release 创建权限的维护者都可随时创建 Release但指南建议先在 Discord 与其他维护者沟通至少获得一位其他维护者的认可再发布。一个重要的例外是若破坏性变更与安全相关可能不 bump major 版本但发布者必须在 Release Notes 头条醒目提示该变更的影响。Release Notes 的推荐结构GitHub 会自动聚合提交这是很好的起点但在此基础上应补充三个小节New Features——本次引入的新功能配截图效果更佳Bug Fixes——显著的 Bug 修复小修复可省略提交信息中已有记录Breaking Changes——本次引入的破坏性变更应当罕见。源码中的自动化补充Release Drafter虽然指南未展开仓库里还预置了 .github/release-drafter.yml 与 .github/workflows/release-drafter.ymlrelease-drafterv7在每次推送mealie-next时自动维护一份草稿 Release按标签归类变更breaking-change/major归入“Breaking changes”feature/minor归入“New features”bugfix归入“Bug fixes”另有 Maintenance、Documentation、Internal development、Dependency updates 等类别通过version-resolver依据 PR 标签自动解析下一个版本号有 major 标签则升 major有 feature/minor 标签则升 minor否则默认 patchautolabeler根据 PR 标题正则/feat/i、/fix:/i、/docs:/i、/chore/i、/dev:/i自动打标签配合 .github/semantic.ymltitleAndCommits: true校验 PR 标题与全部提交保证提交信息与标签的一致性让“Generate release notes”得到高质量的输入。结语一套可复用的开源维护范式Mealie 的维护者实践可以归纳为三个可复用的原则Issue 进入统一入口、评审后明确分诊版本语义化、发布全自动化自动化负责提醒与聚合、人工负责最终决策。无论你是 Mealie 的贡献者还是想为自有项目建立类似流程都可以把 .github/workflows/release.yml、.github/workflows/nightly.yml 与 .github/release-drafter.yml 作为参照模板落地。【免费下载链接】mealieMealie is a self hosted recipe manager and meal planner with a RestAPI backend and a reactive frontend application built in Vue for a pleasant user experience for the whole family. Easily add recipes into your database by providing the url and mealie will automatically import the relevant data or add a family recipe with the UI editor项目地址: https://gitcode.com/GitHub_Trending/me/mealie创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Mealie 维护者指南：Issue 三态工作流与基于 GitHub Actions 的自动化发版全流程
Mealie 维护者指南Issue 三态工作流与基于 GitHub Actions 的自动化发版全流程【免费下载链接】mealieMealie is a self hosted recipe manager and meal planner with a RestAPI backend and a reactive frontend application built in Vue for a pleasant user experience for the whole family. Easily add recipes into your database by providing the url and mealie will automatically import the relevant data or add a family recipe with the UI editor项目地址: https://gitcode.com/GitHub_Trending/me/mealieMealie自托管菜谱管理与膳食规划系统为仓库维护者沉淀了一套可落地的协作规范从 Issue 进入仓库时的bugtriage双标签到确认后归入bug:confirmed或needs more info两态再到“起草 GitHub Release 即完成镜像发布”的纯自动化发版链路。本文以 docs/docs/contributors/developers-guide/maintainers.md 为骨架结合仓库内的 GitHub Actions 工作流与 Issue 模板源码还原这套维护工作流的真实实现帮助你理解并复用 Mealie 的维护实践。谁适合阅读本文已受邀加入 Mealie GitHub 组织、希望承担维护职责的贡献者想深度参与 Mealie 开发者社区、承担 Issue 评审与发版职责的社区成员希望为自己的开源项目引入“自动化发版 规范化 Issue 治理”模式的仓库维护者。仓库根目录的 MAINTAINERS.md 只是入口仓库根目录的 MAINTAINERS.md 仅有一行跳转真正的维护者指南位于 docs/docs/contributors/developers-guide/maintainers.md与building-packages.md、code-contributions.md、database-changes.md、migration-guide.md、starting-dev-server.md等文档共同构成开发者指南位于 docs/docs/contributors/developers-guide。本文即基于该指南原文展开并用仓库源码验证其中的每一条流程。Managing IssuesIssue 的三态评审工作流入口bugtriage双标签当新 Issue 提交到仓库时会自动被打上bug和triage两个标签表示“这是一个待维护者评审、判断有效性的候选”。这套默认标签定义在 .github/ISSUE_TEMPLATE/bug-report.yaml 中name: Bug Report description: Submit a bug for the latest version of Mealie title: [BUG] - YOUR DESCRIPTIVE TITLE GOES HERE labels: [bug, triage]也就是说使用标准 Bug Report 模板提交的 Issue 从创建那一刻起就带上了评审标记维护者需要对其做有效性判断。评审后的一进二两种去向维护者评审一个 Issue 后它通常会进入以下两种状态之一状态含义后续动作bug:confirmed维护者成功复现了该问题确认需要修复进入修复队列等待 PR 修复needs more info原始报告信息不足无法确认问题等待报告者补充信息若报告者未补充Issue 会被自动关闭无论归入哪一种评审完成并重新分类后维护者都应移除triage标签表示该 Issue 已进入正式流转而非待评审状态。评审时的四条实操准则指南明确给出了处理 Issue 时应该遵循的原则允许忽略低质量 Issue——遇到低质量报告直接忽略完全合理对未按标准模板提交的 Issue 应关闭并请报告者使用正确模板重新提交不要尝试复现缺少清晰复现步骤、未提供版本号或描述含糊的 Issue非 Bug 类 Issue 应转为 Discussion在 .github/ISSUE_TEMPLATE/config.yml 中Feature Request 就通过 contact links 定向到 GitHub Discussions与 bug 通道彻底分流。标准模板要求报告者提供“复现步骤、相关日志、Mealie 版本、部署方式”这正是评审时判断信息是否充分的基础例如 bug-report.yaml 中validations.required强制要求填写复现步骤与日志并用 dropdown 收集 Docker/Unraid/TrueNAS 等部署环境让维护者能快速定位环境相关因素。自动化兜底90 天 stale 机制指南中“未补充信息将自动关闭”的兜底动作由 .github/workflows/stale.yml 实现每天定时cron30 1 * * *运行对 90 天无活动的 Issue/PR 打上stale标签但days-before-issue-close: -1意味着仅标记、不自动关闭。同时pinned、security、bug: confirmed、feedback、task等标签被豁免带里程碑的 Issue/PR 也全部豁免——这从源码层面印证了指南的“信息不足才关闭”原则自动流程负责提醒人工决策负责关闭。Drafting Releases从 GitHub Release 到 Docker 镜像的自动化发版Mealie 的发布体系完全构建在 GitHub Actions 之上因此“创建一个新 GitHub Release”就等于“发布一个新版本镜像”。镜像标签矩阵镜像标签发布时机触发工作流ghcr.io/mealie-recipes/mealie:nightly每次推送到mealie-next分支.github/workflows/nightly.ymlghcr.io/mealie-recipes/mealie:latest创建新的 GitHub Release.github/workflows/release.ymlghcr.io/mealie-recipes/mealie:{version}创建新的 GitHub Release.github/workflows/release.yml注意latest与{version}两个标签在发布新版本时指向同一份镜像。实际构建链路验证nightly 链路nightly.yml监听对mealie-next分支的 push并忽略*.md、.vscode/**、docs/**等纯文档变更依次运行后端测试、前端测试、构建 Python 包最后调用publish.yml以nightly标签构建并推送镜像完成后通过 Discord Webhook 通知DISCORD_NIGHTLY_WEBHOOK。release 链路release.yml监听release: published事件先由commit-version-bump作业自动从 tag 提取版本号sed s/^v//批量改写 pyproject.toml、uv.lock、frontend/package.json 以及三处安装文档中的版本字符串并提交提交者身份为mealie-commit-bot[bot]随后把 release tag 移到新提交上接下来并行执行后端/前端测试与打包全部通过后由publish作业构建并推送hkotel/mealie:latest与ghcr.io/...:latest。版本号来源指南强调“不要手动改代码里的版本号”。版本号由 release tag 在构建时注入publish.yml 通过docker/metadata-action覆盖org.opencontainers.image.version标签并以COMMITbuild-arg 传入 commit SHA实现了“代码零版本号、tag 即版本”的自动注入。失败自动回滚若publish失败release.yml的rollback-on-failure作业会删除 release tag、revert 版本号提交避免留下“tag 存在但镜像未发布”的脏状态。发布前通过DISCORD_RELEASE_WEBHOOK在 Discord 发布“版本已发布”通知与 nightly 通知形成完整的信息闭环。起草 Release 的四步流程进入 GitHub Release 页面点击Draft a new release选择 tag并按语义化版本SemVer递增major对应破坏性变更、minor对应新功能、patch对应 Bug 修复命名 Release通常直接用 tag 名即可若有值得突出的特性可以在名称中体现点击Generate release notes由 GitHub 自动把自上个 Release 以来的全部提交拉入变更日志。纯 Bug 修复型版本这已经足够若有重大特性或体验优化应在完整变更日志之前单独成段说明。Tags 与 Releases 的版本策略Mealie 严格遵循 Semver 策略力求版本稳定Major仅用于破坏性变更预期不会频繁出现短期内保持 v1.x.xMinor用于新功能更新频繁Patch用于 Bug 修复更新频繁。任何具备 Release 创建权限的维护者都可随时创建 Release但指南建议先在 Discord 与其他维护者沟通至少获得一位其他维护者的认可再发布。一个重要的例外是若破坏性变更与安全相关可能不 bump major 版本但发布者必须在 Release Notes 头条醒目提示该变更的影响。Release Notes 的推荐结构GitHub 会自动聚合提交这是很好的起点但在此基础上应补充三个小节New Features——本次引入的新功能配截图效果更佳Bug Fixes——显著的 Bug 修复小修复可省略提交信息中已有记录Breaking Changes——本次引入的破坏性变更应当罕见。源码中的自动化补充Release Drafter虽然指南未展开仓库里还预置了 .github/release-drafter.yml 与 .github/workflows/release-drafter.ymlrelease-drafterv7在每次推送mealie-next时自动维护一份草稿 Release按标签归类变更breaking-change/major归入“Breaking changes”feature/minor归入“New features”bugfix归入“Bug fixes”另有 Maintenance、Documentation、Internal development、Dependency updates 等类别通过version-resolver依据 PR 标签自动解析下一个版本号有 major 标签则升 major有 feature/minor 标签则升 minor否则默认 patchautolabeler根据 PR 标题正则/feat/i、/fix:/i、/docs:/i、/chore/i、/dev:/i自动打标签配合 .github/semantic.ymltitleAndCommits: true校验 PR 标题与全部提交保证提交信息与标签的一致性让“Generate release notes”得到高质量的输入。结语一套可复用的开源维护范式Mealie 的维护者实践可以归纳为三个可复用的原则Issue 进入统一入口、评审后明确分诊版本语义化、发布全自动化自动化负责提醒与聚合、人工负责最终决策。无论你是 Mealie 的贡献者还是想为自有项目建立类似流程都可以把 .github/workflows/release.yml、.github/workflows/nightly.yml 与 .github/release-drafter.yml 作为参照模板落地。【免费下载链接】mealieMealie is a self hosted recipe manager and meal planner with a RestAPI backend and a reactive frontend application built in Vue for a pleasant user experience for the whole family. Easily add recipes into your database by providing the url and mealie will automatically import the relevant data or add a family recipe with the UI editor项目地址: https://gitcode.com/GitHub_Trending/me/mealie创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考