Docker Mail Server 贡献指南从提交 Issue 到合并 Pull Request 的完整工作流【免费下载链接】docker-mailserverProduction-ready fullstack but simple mail server (SMTP, IMAP, LDAP, Antispam, Antivirus, etc.) running inside a container.项目地址: https://gitcode.com/gh_mirrors/do/docker-mailserverDMSDocker Mail Server是一个开源的容器化全栈邮件服务器项目SMTP、IMAP、LDAP、反垃圾、反病毒等。本篇指南围绕 issues-and-pull-requests.md 展开系统讲解 DMS 社区贡献者如何正确提交 Bug 报告、如何按官方工作流提交 Pull Request并结合仓库内的 Issue 模板、Makefile、lint 脚本与测试套件给出可直接落地的实操细节。读完本文你将掌握提交 Issue 前必须完成的自我排查清单、如何用LOG_LEVEL收集有效日志、Issue/PR 模板的具体字段要求以及从 fork、lint、测试到合并、发布:edge镜像的完整开发闭环。项目背景开源的 DMS 如何接受贡献DMS 是完全开源的因此任何人都可以参与其中增强功能enhancements、修复缺陷bug fixing或改进文档improving the documentation都是有效的贡献方式。与多数成熟开源项目一样DMS 的贡献协作发生在两个层面Issue 跟踪器用于报告缺陷、讨论新功能与提出疑问Pull Request用于提交经过验证的代码/文档改动最终合并进master分支。仓库的 README.md、CODE_OF_CONDUCT.md 与 SECURITY.md 是参与协作前应通读的基础文件。其中 SECURITY.md 规定了安全漏洞的私下报告渠道安全相关问题不应直接暴露在公开 Issue 中。提交 Issue先自助排查再找社区强制前置要求开 Issue 之前先做功课原文档明确要求在打开 Issue 之前必须依次完成以下排查仔细阅读项目的README研究与你所用版本匹配的文档文档站点提供了版本选择器建议使用latest或与镜像 tag 对应的版本查阅 Postfix 与 Dovecot 的官方文档DMS 的核心组件使用你信任的搜索引擎检索是否已有相同问题。!!! attention**Issue 跟踪器不用于回答与本项目无关的问题** 如果问题与 DMS 无关请到对应的上游项目如 Postfix、Dovecot、Rspamd寻求帮助。这一要求的背后是维护成本考量DMS 的维护者与版主都是志愿者花费大量时间改进项目、协同解决问题。因此社区期望每位报告者都遵守规则、付出努力用高质量的信息换取高效率的协作。用 LOG_LEVEL 收集可复现日志当打开 Issue 时请提供足够详细的用例use case让社区能够复现你的问题。文档给出的标准做法是以debug或trace级别启动 DMS并把输出粘贴到 Issue 中。具体实现上environment.md 定义了LOG_LEVEL环境变量它主要用于容器启动脚本与变更检测change detection事件的日志反馈有效取值按详细程度递增为error、warn、info、debug、trace默认值为info。也就是说# compose.yaml 中的典型用法 services: mailserver: image: ghcr.io/docker-mailserver/docker-mailserver:edge environment: LOG_LEVEL: trace # 或 debug从源码结构看该环境变量在容器启动阶段即被读取并在target/scripts/helpers/log.sh中驱动日志输出过滤。trace级别会在启动与配置生成阶段输出最详尽的信息是定位配置生成问题时的首选若日志量过大可先用debug缩小范围。Bug 报告模板的日志字段也提示用户可通过设置环境变量LOG_LEVEL为debug或trace来启用调试输出二者完全呼应。必须使用 Issue 模板!!! attention**请使用 Issue 模板提供必要信息。不使用模板的 Issue 不会被处理并将被直接关闭。**仓库中实际提供了三份模板与一个路由配置位于 .github/ISSUE_TEMPLATE/ 目录文件用途bug_report.yml缺陷报告含逐字段校验必填项feature_request.yml功能请求引导填写动机、方案与受众config.yml路由配置blank_issues_enabled: false即禁用空白 Issue并提供文档相关 contact link 引导用户先去查阅资料其中 config.yml 的三条 contact link 依次指向文档首页、环境变量页对应 environment.md与调试页对应 debugging.md。这再次印证了先查文档再开 Issue的项目铁律。提交 Bug 报告的正确姿势Bug 报告是社区最宝贵的输入之一。文档强调以下几点DMS 是社区驱动项目每一份贡献都算数但维护者与版主是志愿者只有通过模板提供详细信息的报告才能得到最快、最好的帮助忽略模板可能显得省事但会降低获得支持的概率——此类 Issue 会被打上meta/no template - no support标签意味着维护者不再承诺响应几乎所有文本字段都支持 Markdown 格式除非字段描述中明确说明不支持宁可多写也不要写太少——尽量精确信息不足时补充更多细节比遗漏更好若某个选项被标记为not officially supported / unsupported其支持程度取决于是否有空闲的特定维护者不应默认承诺。Bug 报告模板字段逐项解析参考 bug_report.yml一份合格的 Bug 报告至少包含 Preliminary Checks前置检查——两个必勾选项已搜索现有 Issue 并遵循调试文档建议但仍需帮助披露使用过的 AI 辅助工具报告者必须声明提交的信息中是否使用了 AI 辅助以免浪费志愿者的时间。 What Happened?——实际行为与预期的差异必填占位示例即LOG_LEVELdebug已设置但日志缺少 debug 输出 Reproduction Steps——逐步复现路径必填大段文本建议使用围栏代码块fenced code blocks格式化 DMS Version——遇到缺陷的镜像 tag必填占位提示为v12.1.0且不要写 latest Operating System and Architecture——Docker 宿主机的 OS 与架构必填占位如Debian 11 (Bullseye) x86_64、Fedora 38 ARM64同时注明 Windows 与 macOS 支持受限⚙️ Container configuration files——以 YAML 格式展示运行 DMS 的compose.yaml或docker run命令使用 Kubernetes 时可提供清单文件 Relevant log output——相关日志输出纯文本、自动渲染为代码块。在 Issue 正文中提交即同意项目条款了解 Issue 跟踪器的规则将同时帮助维护者与所有人更快找到解决方案。功能请求先讨论再动手原文档对新增功能给出了一条温和但重要的建议动手实现之前先创建 Issue 说明你想做什么、打算怎么做。理由很务实其他用户可能有相同需求讨论与协作可能带来更好的方案避免大量未经讨论的重复劳动。仓库中的 feature_request.yml 将这一思路落实为必填字段Context与 DMS 或某个组件/Issue/PR 的关联必须链接相关 Issue 与 PR、Description期望的实现方案尽量精确、Alternatives考虑过的替代方案、Applicable Users该功能对谁有用以及一个二选一的下拉框是我会实现它——因为知道别人实现它的概率低且自己能从中学习否——并理解很可能无人实现、Issue 会逐渐过时stale并被关闭。这个设计巧妙地把提需求与背责任绑定在一起从机制上减少了无人认领的僵尸需求。提交 Pull Request官方开发工作流标准流程六步走原文档给出的 PR 提交流程如下Fork 项目并克隆你的 fork使用git clone --recurse-submodules ...若已克隆则在项目根目录运行git submodule update --init --recursive。编写所需代码。必要时补充集成测试。准备环境并运行 lint 与测试对应文档 tests.md。必要时补充文档例如引入了新的环境变量需在 环境变量文档 中描述并在CHANGELOG.md的 Unreleased 一节登记改动。提交并签名push 后创建 PR 合入master请使用 Pull Request 模板提供最低限度的上下文信息并勾选清单中的每一项要求。为什么必须初始化 git submoduleDMS 的测试依赖 BATSBash Automated Testing System及其支持库这些以 submodule 形式引入。查看仓库根目录的 .gitmodules 可以看到三个子模块test/bats→ bats-core/bats-coretest/test_helper/bats-support→ bats-core/bats-supporttest/test_helper/bats-assert→ bats-core/bats-assert因此克隆 fork 时必须带上--recurse-submodules或在克隆后执行git submodule update --init --recursive否则test/bats/bin/bats不存在测试将无法运行。代码风格与 lint合并前置门槛提交代码前请遵守 general.md 中定义的编码规范调整自己的风格以适应当前已存在的风格——即使你不喜欢它这是为了全局一致性项目曾投入大量工作统一全部脚本风格使用shellcheck检查脚本——GitHub Actions CI 也会做同样检查所以本地必须先通过可以用make lint一键检查全部目标使用仓库提供的.editorconfig文件脚本使用/bin/bash而非/bin/sh。从 Makefile 看make lint会依次触发四个检查目标hadolint基于 .hadolint.yml 检查Dockerfilebashcheck对所有.sh与target/bin下的脚本执行bash -n语法校验shellcheck对脚本与.bats测试文件分别执行静态检查.bats因自定义test语法需额外排除若干规则eclint用 editorconfig-checker 校验文件格式是否符合.editorconfig。对应的实现细节见 test/linting/lint.shlint 通过 Docker 容器执行如hadolint/hadolint:v2.12.0-alpine、koalaman/shellcheck-alpine:v0.9.0、mstruebing/editorconfig-checker:2.7.2将仓库根目录只读挂载到容器内保证任何开发环境下结果一致。测试改动必须经过验证文档 tests.md 指出DMS 采用 BATS 编写单元与集成测试全部测试与相关配置位于test/目录要改动既有功能或集成新特性大概率需要与测试套件打交道。常用命令由 Makefile 提供# 构建本地测试镜像 $ make build # 运行全部测试serial 三个 parallel set $ make clean tests # 运行单个测试文件去掉 .bats 后缀 $ make clean generate-accounts test/rspamd # 运行多个不相关的测试文件用逗号分隔 $ make clean generate-accounts test/rspamd,clamav # 运行某个 parallel set 或全部 serial 测试 $ make clean generate-accounts tests/parallel/set1 $ make clean generate-accounts tests/serial相关要点并行度BATS_PARALLEL_JOBS默认值为 2见 Makefile资源充裕时可增大设为 1 可强制串行并行测试的输出延迟以并行方式运行时BATS 会推迟到文件内全部用例结束才输出结果故障定位时建议先串行复跑相关用例本地调试实例make run-local-instance可基于本地构建镜像启动一个启用LOG_LEVELtrace的实例方便边改边验证该命令默认关闭 ClamAV、Amavis、Rspamd、OpenDKIM、OpenDMARC、SpamAssassin 与 policyd-spf见 Makefile测试目录结构test/tests/parallel/并行多文件并发以缩短耗时与test/tests/serial/串行无法并发的测试两类并行测试又被细分为set1/set2/set3CI 会把这些 set 分发到多个 runner 上并行执行。文档与 CHANGELOG功能变更的售后服务若你的改动引入了新的环境变量必须在 environment.md 中补充说明该文档首页注明加粗值为默认值当前master分支对应镜像 tag:edge同时把改动登记到 CHANGELOG.md 的 Unreleased 一节。文档 general.md 还提供了本地预览文档的方法——从 git clone 的根目录执行docker run --rm -it -p 8000:8000 -v ./docs:/docs docker.io/squidfunk/mkdocs-material:9.7即可在http://localhost:8000实时预览文档每次保存都会热重载。文档站点的构建配置见 mkdocs.yml。容器日志会报告检测到的无效链接但有少量误报源于内容标签页的锚点链接用法。提交、签名与创建 PRCommit 信息建议让提交信息直接关联并关闭对应 Issuecommit message 中的关闭引用签名提交请为提交配置 GPG 签名git commit --gpg-signPR 模板务必使用 Pull Request 模板提供最低限度的上下文信息并满足清单中的全部勾选项。PR 提交后的自动验证与发布链路原文档明确了 PR 的后续流程Pull requests are automatically tested against the CI and will be reviewed when tests pass. When your changes are validated, your branch is merged. CI builds the new:edgeimage immediately and your changes will be included in the next version release.即PR 会被 CI 自动测试测试通过后进入人工评审改动验证通过后分支被合并CI 立即构建新的:edge镜像改动将包含在下一个版本发布中。从仓库的 workflow 文件可以印证这条链路位于 .github/workflows/ 目录test_merge_requests.yml针对合并请求触发测试linting.yml运行上文所述 lint 检查generic_test.yml、generic_build.yml通用构建与测试流水线generic_publish.yml构建并发布镜像master合入后产出:edgegeneric_vulnerability-scan.yml镜像漏洞扫描。另有 docs-production-deploy.yml 与 docs-preview-deploy.yml 负责文档站点的生产发布与 PR 预览部署handle_stalled.yml 则用于处理停滞的 Issue/PR。因此CI 通过 → 评审 → 合并 → 自动发布:edge是一条完全自动化的流水线贡献者只需保证本地 lint 与测试全绿。总结一份 DMS 贡献者的行动清单无论你是报告问题的用户还是提交代码的开发者都可以用下面的清单快速自查提交 Issue 前已通读 README 与对应版本的 文档已检索现有 Issue确认不是重复报告已以LOG_LEVELdebug或trace启动容器收集可复现日志使用 bug_report.yml 或 feature_request.yml 模板填写全部必填字段声明是否使用了 AI 辅助工具提交 PR 前Fork 后用git clone --recurse-submodules克隆或已执行git submodule update --init --recursive代码风格符合 general.md 与.editorconfigmake lint全部通过make clean tests或至少相关测试文件通过新环境变量已写入 environment.md改动已登记到 CHANGELOG.md 的 Unreleased提交已 GPG 签名PR 使用模板并勾选全部清单项遵循这套流程既是对维护者志愿时间的尊重也能让你的 Issue 更快得到响应、让你的代码更顺畅地进入下一个 DMS 版本。【免费下载链接】docker-mailserverProduction-ready fullstack but simple mail server (SMTP, IMAP, LDAP, Antispam, Antivirus, etc.) running inside a container.项目地址: https://gitcode.com/gh_mirrors/do/docker-mailserver创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Docker Mail Server 贡献指南：从提交 Issue 到合并 Pull Request 的完整工作流
Docker Mail Server 贡献指南从提交 Issue 到合并 Pull Request 的完整工作流【免费下载链接】docker-mailserverProduction-ready fullstack but simple mail server (SMTP, IMAP, LDAP, Antispam, Antivirus, etc.) running inside a container.项目地址: https://gitcode.com/gh_mirrors/do/docker-mailserverDMSDocker Mail Server是一个开源的容器化全栈邮件服务器项目SMTP、IMAP、LDAP、反垃圾、反病毒等。本篇指南围绕 issues-and-pull-requests.md 展开系统讲解 DMS 社区贡献者如何正确提交 Bug 报告、如何按官方工作流提交 Pull Request并结合仓库内的 Issue 模板、Makefile、lint 脚本与测试套件给出可直接落地的实操细节。读完本文你将掌握提交 Issue 前必须完成的自我排查清单、如何用LOG_LEVEL收集有效日志、Issue/PR 模板的具体字段要求以及从 fork、lint、测试到合并、发布:edge镜像的完整开发闭环。项目背景开源的 DMS 如何接受贡献DMS 是完全开源的因此任何人都可以参与其中增强功能enhancements、修复缺陷bug fixing或改进文档improving the documentation都是有效的贡献方式。与多数成熟开源项目一样DMS 的贡献协作发生在两个层面Issue 跟踪器用于报告缺陷、讨论新功能与提出疑问Pull Request用于提交经过验证的代码/文档改动最终合并进master分支。仓库的 README.md、CODE_OF_CONDUCT.md 与 SECURITY.md 是参与协作前应通读的基础文件。其中 SECURITY.md 规定了安全漏洞的私下报告渠道安全相关问题不应直接暴露在公开 Issue 中。提交 Issue先自助排查再找社区强制前置要求开 Issue 之前先做功课原文档明确要求在打开 Issue 之前必须依次完成以下排查仔细阅读项目的README研究与你所用版本匹配的文档文档站点提供了版本选择器建议使用latest或与镜像 tag 对应的版本查阅 Postfix 与 Dovecot 的官方文档DMS 的核心组件使用你信任的搜索引擎检索是否已有相同问题。!!! attention**Issue 跟踪器不用于回答与本项目无关的问题** 如果问题与 DMS 无关请到对应的上游项目如 Postfix、Dovecot、Rspamd寻求帮助。这一要求的背后是维护成本考量DMS 的维护者与版主都是志愿者花费大量时间改进项目、协同解决问题。因此社区期望每位报告者都遵守规则、付出努力用高质量的信息换取高效率的协作。用 LOG_LEVEL 收集可复现日志当打开 Issue 时请提供足够详细的用例use case让社区能够复现你的问题。文档给出的标准做法是以debug或trace级别启动 DMS并把输出粘贴到 Issue 中。具体实现上environment.md 定义了LOG_LEVEL环境变量它主要用于容器启动脚本与变更检测change detection事件的日志反馈有效取值按详细程度递增为error、warn、info、debug、trace默认值为info。也就是说# compose.yaml 中的典型用法 services: mailserver: image: ghcr.io/docker-mailserver/docker-mailserver:edge environment: LOG_LEVEL: trace # 或 debug从源码结构看该环境变量在容器启动阶段即被读取并在target/scripts/helpers/log.sh中驱动日志输出过滤。trace级别会在启动与配置生成阶段输出最详尽的信息是定位配置生成问题时的首选若日志量过大可先用debug缩小范围。Bug 报告模板的日志字段也提示用户可通过设置环境变量LOG_LEVEL为debug或trace来启用调试输出二者完全呼应。必须使用 Issue 模板!!! attention**请使用 Issue 模板提供必要信息。不使用模板的 Issue 不会被处理并将被直接关闭。**仓库中实际提供了三份模板与一个路由配置位于 .github/ISSUE_TEMPLATE/ 目录文件用途bug_report.yml缺陷报告含逐字段校验必填项feature_request.yml功能请求引导填写动机、方案与受众config.yml路由配置blank_issues_enabled: false即禁用空白 Issue并提供文档相关 contact link 引导用户先去查阅资料其中 config.yml 的三条 contact link 依次指向文档首页、环境变量页对应 environment.md与调试页对应 debugging.md。这再次印证了先查文档再开 Issue的项目铁律。提交 Bug 报告的正确姿势Bug 报告是社区最宝贵的输入之一。文档强调以下几点DMS 是社区驱动项目每一份贡献都算数但维护者与版主是志愿者只有通过模板提供详细信息的报告才能得到最快、最好的帮助忽略模板可能显得省事但会降低获得支持的概率——此类 Issue 会被打上meta/no template - no support标签意味着维护者不再承诺响应几乎所有文本字段都支持 Markdown 格式除非字段描述中明确说明不支持宁可多写也不要写太少——尽量精确信息不足时补充更多细节比遗漏更好若某个选项被标记为not officially supported / unsupported其支持程度取决于是否有空闲的特定维护者不应默认承诺。Bug 报告模板字段逐项解析参考 bug_report.yml一份合格的 Bug 报告至少包含 Preliminary Checks前置检查——两个必勾选项已搜索现有 Issue 并遵循调试文档建议但仍需帮助披露使用过的 AI 辅助工具报告者必须声明提交的信息中是否使用了 AI 辅助以免浪费志愿者的时间。 What Happened?——实际行为与预期的差异必填占位示例即LOG_LEVELdebug已设置但日志缺少 debug 输出 Reproduction Steps——逐步复现路径必填大段文本建议使用围栏代码块fenced code blocks格式化 DMS Version——遇到缺陷的镜像 tag必填占位提示为v12.1.0且不要写 latest Operating System and Architecture——Docker 宿主机的 OS 与架构必填占位如Debian 11 (Bullseye) x86_64、Fedora 38 ARM64同时注明 Windows 与 macOS 支持受限⚙️ Container configuration files——以 YAML 格式展示运行 DMS 的compose.yaml或docker run命令使用 Kubernetes 时可提供清单文件 Relevant log output——相关日志输出纯文本、自动渲染为代码块。在 Issue 正文中提交即同意项目条款了解 Issue 跟踪器的规则将同时帮助维护者与所有人更快找到解决方案。功能请求先讨论再动手原文档对新增功能给出了一条温和但重要的建议动手实现之前先创建 Issue 说明你想做什么、打算怎么做。理由很务实其他用户可能有相同需求讨论与协作可能带来更好的方案避免大量未经讨论的重复劳动。仓库中的 feature_request.yml 将这一思路落实为必填字段Context与 DMS 或某个组件/Issue/PR 的关联必须链接相关 Issue 与 PR、Description期望的实现方案尽量精确、Alternatives考虑过的替代方案、Applicable Users该功能对谁有用以及一个二选一的下拉框是我会实现它——因为知道别人实现它的概率低且自己能从中学习否——并理解很可能无人实现、Issue 会逐渐过时stale并被关闭。这个设计巧妙地把提需求与背责任绑定在一起从机制上减少了无人认领的僵尸需求。提交 Pull Request官方开发工作流标准流程六步走原文档给出的 PR 提交流程如下Fork 项目并克隆你的 fork使用git clone --recurse-submodules ...若已克隆则在项目根目录运行git submodule update --init --recursive。编写所需代码。必要时补充集成测试。准备环境并运行 lint 与测试对应文档 tests.md。必要时补充文档例如引入了新的环境变量需在 环境变量文档 中描述并在CHANGELOG.md的 Unreleased 一节登记改动。提交并签名push 后创建 PR 合入master请使用 Pull Request 模板提供最低限度的上下文信息并勾选清单中的每一项要求。为什么必须初始化 git submoduleDMS 的测试依赖 BATSBash Automated Testing System及其支持库这些以 submodule 形式引入。查看仓库根目录的 .gitmodules 可以看到三个子模块test/bats→ bats-core/bats-coretest/test_helper/bats-support→ bats-core/bats-supporttest/test_helper/bats-assert→ bats-core/bats-assert因此克隆 fork 时必须带上--recurse-submodules或在克隆后执行git submodule update --init --recursive否则test/bats/bin/bats不存在测试将无法运行。代码风格与 lint合并前置门槛提交代码前请遵守 general.md 中定义的编码规范调整自己的风格以适应当前已存在的风格——即使你不喜欢它这是为了全局一致性项目曾投入大量工作统一全部脚本风格使用shellcheck检查脚本——GitHub Actions CI 也会做同样检查所以本地必须先通过可以用make lint一键检查全部目标使用仓库提供的.editorconfig文件脚本使用/bin/bash而非/bin/sh。从 Makefile 看make lint会依次触发四个检查目标hadolint基于 .hadolint.yml 检查Dockerfilebashcheck对所有.sh与target/bin下的脚本执行bash -n语法校验shellcheck对脚本与.bats测试文件分别执行静态检查.bats因自定义test语法需额外排除若干规则eclint用 editorconfig-checker 校验文件格式是否符合.editorconfig。对应的实现细节见 test/linting/lint.shlint 通过 Docker 容器执行如hadolint/hadolint:v2.12.0-alpine、koalaman/shellcheck-alpine:v0.9.0、mstruebing/editorconfig-checker:2.7.2将仓库根目录只读挂载到容器内保证任何开发环境下结果一致。测试改动必须经过验证文档 tests.md 指出DMS 采用 BATS 编写单元与集成测试全部测试与相关配置位于test/目录要改动既有功能或集成新特性大概率需要与测试套件打交道。常用命令由 Makefile 提供# 构建本地测试镜像 $ make build # 运行全部测试serial 三个 parallel set $ make clean tests # 运行单个测试文件去掉 .bats 后缀 $ make clean generate-accounts test/rspamd # 运行多个不相关的测试文件用逗号分隔 $ make clean generate-accounts test/rspamd,clamav # 运行某个 parallel set 或全部 serial 测试 $ make clean generate-accounts tests/parallel/set1 $ make clean generate-accounts tests/serial相关要点并行度BATS_PARALLEL_JOBS默认值为 2见 Makefile资源充裕时可增大设为 1 可强制串行并行测试的输出延迟以并行方式运行时BATS 会推迟到文件内全部用例结束才输出结果故障定位时建议先串行复跑相关用例本地调试实例make run-local-instance可基于本地构建镜像启动一个启用LOG_LEVELtrace的实例方便边改边验证该命令默认关闭 ClamAV、Amavis、Rspamd、OpenDKIM、OpenDMARC、SpamAssassin 与 policyd-spf见 Makefile测试目录结构test/tests/parallel/并行多文件并发以缩短耗时与test/tests/serial/串行无法并发的测试两类并行测试又被细分为set1/set2/set3CI 会把这些 set 分发到多个 runner 上并行执行。文档与 CHANGELOG功能变更的售后服务若你的改动引入了新的环境变量必须在 environment.md 中补充说明该文档首页注明加粗值为默认值当前master分支对应镜像 tag:edge同时把改动登记到 CHANGELOG.md 的 Unreleased 一节。文档 general.md 还提供了本地预览文档的方法——从 git clone 的根目录执行docker run --rm -it -p 8000:8000 -v ./docs:/docs docker.io/squidfunk/mkdocs-material:9.7即可在http://localhost:8000实时预览文档每次保存都会热重载。文档站点的构建配置见 mkdocs.yml。容器日志会报告检测到的无效链接但有少量误报源于内容标签页的锚点链接用法。提交、签名与创建 PRCommit 信息建议让提交信息直接关联并关闭对应 Issuecommit message 中的关闭引用签名提交请为提交配置 GPG 签名git commit --gpg-signPR 模板务必使用 Pull Request 模板提供最低限度的上下文信息并满足清单中的全部勾选项。PR 提交后的自动验证与发布链路原文档明确了 PR 的后续流程Pull requests are automatically tested against the CI and will be reviewed when tests pass. When your changes are validated, your branch is merged. CI builds the new:edgeimage immediately and your changes will be included in the next version release.即PR 会被 CI 自动测试测试通过后进入人工评审改动验证通过后分支被合并CI 立即构建新的:edge镜像改动将包含在下一个版本发布中。从仓库的 workflow 文件可以印证这条链路位于 .github/workflows/ 目录test_merge_requests.yml针对合并请求触发测试linting.yml运行上文所述 lint 检查generic_test.yml、generic_build.yml通用构建与测试流水线generic_publish.yml构建并发布镜像master合入后产出:edgegeneric_vulnerability-scan.yml镜像漏洞扫描。另有 docs-production-deploy.yml 与 docs-preview-deploy.yml 负责文档站点的生产发布与 PR 预览部署handle_stalled.yml 则用于处理停滞的 Issue/PR。因此CI 通过 → 评审 → 合并 → 自动发布:edge是一条完全自动化的流水线贡献者只需保证本地 lint 与测试全绿。总结一份 DMS 贡献者的行动清单无论你是报告问题的用户还是提交代码的开发者都可以用下面的清单快速自查提交 Issue 前已通读 README 与对应版本的 文档已检索现有 Issue确认不是重复报告已以LOG_LEVELdebug或trace启动容器收集可复现日志使用 bug_report.yml 或 feature_request.yml 模板填写全部必填字段声明是否使用了 AI 辅助工具提交 PR 前Fork 后用git clone --recurse-submodules克隆或已执行git submodule update --init --recursive代码风格符合 general.md 与.editorconfigmake lint全部通过make clean tests或至少相关测试文件通过新环境变量已写入 environment.md改动已登记到 CHANGELOG.md 的 Unreleased提交已 GPG 签名PR 使用模板并勾选全部清单项遵循这套流程既是对维护者志愿时间的尊重也能让你的 Issue 更快得到响应、让你的代码更顺畅地进入下一个 DMS 版本。【免费下载链接】docker-mailserverProduction-ready fullstack but simple mail server (SMTP, IMAP, LDAP, Antispam, Antivirus, etc.) running inside a container.项目地址: https://gitcode.com/gh_mirrors/do/docker-mailserver创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考