Dokku 贡献指南从提交 Issue 到合并 Pull Request 的完整协作流程【免费下载链接】dokkuA docker-powered PaaS that helps you build and manage the lifecycle of applications项目地址: https://gitcode.com/GitHub_Trending/do/dokku导读本文基于 Dokku 仓库根目录的 CONTRIBUTING.md 展开系统讲解向 Dokku一个基于 Docker 的 PaaS 平台提交贡献的完整路径从发现 Bug、撰写高质量 Issue到创建 Topic 分支、遵循编码规范、提交 Pull Request再到在本地运行完整测试套件验证改动。读完本文你将掌握 Dokku 社区认可的协作节奏、分支与提交纪律、合并规则以及如何借助仓库内的 tests.mk、docs/development/testing.md 与 ISSUE_TEMPLATE.md 完成一次合格的代码贡献。参与贡献的多种方式Dokku 项目欢迎各种形式的贡献提交代码补丁只是其中一种。根据 CONTRIBUTING.md 的说明社区认可的参与方式包括提交 Issue发现 Bug 时在项目的 issue 跟踪系统中创建问题报告编写测试用例为尚未解决的 Bug issue 补充测试帮助复现与验证编写补丁为开放的 Bug/Feature issue 提交修复或实现最好附带测试用例贡献文档完善使用手册、教程等官方文档展示项目 Logo以非商业方式展示 Dokku 的 Logo扩大项目影响力撰写博客分享你使用 Dokku 的方式与经验财务赞助通过赞助渠道支持项目持续开发。无论选择哪一条路径都需要遵守一些基本协作准则以保证维护者能够高效地跟进每个人的贡献。安全漏洞走私密报告通道Dokku 维护者对安全问题非常重视。如果你发现了安全漏洞绝对不要提交公开 Issue而是应当立即将报告私密发送至维护者邮箱dokkujosediazgonzalez.com。安全报告会得到高度重视且项目会公开致谢报告者。这是安全研究与普通 Bug 报告之间最重要的流程差异漏洞细节在修复完成前必须保密避免被恶意利用。如何撰写高质量 Bug 报告撰写详尽、结构清晰的 Bug 报告本身就是对项目的重要贡献。在提交 Issue 之前请先完成两步准备工作检索现有 issue 数据库确认你的问题或建议是否已经被报告过若存在相同 issue追加一条 1 或 我也有这个问题 的评论即可这能帮助维护者识别最普遍的问题并排定优先级。正式提交时请按照仓库根目录 ISSUE_TEMPLATE.md 中的模板填写全部信息。结合模板内容一份合格的报告至少应包含问题描述问题的现象、可复现程度、复现步骤、实际结果与期望结果dokku report APP_NAME输出模板中明确标注这是必填项缺失该信息的 Issue 可能被直接关闭。对于影响所有应用的问题可运行不带参数的dokku report查看顶层报告信息安装方式与环境通过deb还是make方式安装运行环境是 AWS、VirtualBox 还是物理机等辅助诊断信息如适用附上dokku ps:inspect APP_NAME的容器检查输出、dokku nginx:show-config APP_NAME的 Nginx 配置部署相关信息应用名称、应用类型node/php/python/ruby 等、使用的自定义 buildpack、Dockerfile内容、Procfile内容追踪输出运行dokku trace:on后执行失败命令的输出。模板特别警告trace:on会打印某些命令的环境变量发布前务必用XXXXXX替换敏感信息避免泄露凭据。同时请在报告中注明你确认最早出现该问题的版本这将显著加速定位与修复。贡献前的准备清单在动手修改代码前CONTRIBUTING.md 要求完成以下准备拥有一个 GitHub 账号提交一个 Issue若尚不存在清晰描述问题Bug 需包含复现步骤Fork 仓库到你的账号下。Making Changes分支策略与提交纪律进入编码阶段后需要遵守明确的分支与提交规范创建 Topic 分支从你希望基于的分支创建 Topic 分支通常基于master除非你确定修复必须落在某个特定分支上否则不要直接以其他分支为目标快速创建基于 master 的 Topic 分支git checkout -b my_contribution origin/master尽量避免直接在master分支上工作——这会减少后续从 origin 拉取更新时产生冲突的概率。以逻辑单元为单位提交每次提交应构成一个逻辑单元例如实现一个新函数并在另一文件中调用它应算作一个完整的工作单元提交 Pull Request 前使用交互式变基整理提交历史git rebase -i git push -f绝大多数提交应该被压缩为单个 commit拿不准时就把改动 squash 成一个提交提交前用git diff --check检查并清理多余的空白字符使用描述性的提交信息并在信息中引用对应的 issue 编号如#123。遵守编码规范Dokku 的 shell 代码遵循 bashstyle 风格约定文档中以 Dokku coding standards 指代。在仓库的 tests.mk 中可以找到与编码规范对应的落地工具链make lint依次执行lint-shfmt调用shfmt -l -bn -ci -i 2 -d .做格式化校验与lint-ci基于 shellcheck 做静态检查并借助 tests/shellcheck-to-junit 将结果转为 JUnit 格式Go 插件则通过golangci-lint校验。也就是说符合编码规范在 CI 中是可自动验证的硬性门禁。保持 PR 干净可合并Pull Request 必须干净地 rebase 到 master 之上不得将多个分支的改动混杂在同一个 PR 中Git 技巧当 PR 无法干净合并时在特性分支中使用rebase master更新你的 PR而不是merge master。分支基线始终基于最新 master所有变更都应基于最新的 master 提交。这是社区合并工作的基线要求确保你的改动与主干保持同步降低冲突与回归风险。提交 Pull Request完成编码与本地验证后将改动推送到你 fork 仓库中的 Topic 分支向原仓库提交 Pull Request并选择正确的目标分支通常是master。合并规则与评审预期提交 PR 后请保持耐心维护者会尽快评审所有 PR 并给出评论期间可能就细节进行多轮往返讨论。若你的 PR 最终未被合并这种情况很少见维护者会提供替代补丁方案或引导你走向更优的解决思路。在项目的 pre-1.0 周期内合并 PR 遵循以下通用规则对应语义化版本号的变化幅度变更类型版本号影响Bug 修复bugfixpatch安全修复securitypatch/minor次要特性minor featurepatch不兼容变更backwards incompatible changeminor主要特性major featureminor这意味着小改动以低版本号增量合入而破坏性或不兼容的改动会以更高的版本号增量发布从而在发布节奏上为下游用户留出缓冲。在本地运行测试把质量门禁前置贡献者应在提交 PR 前自行验证改动。CONTRIBUTING.md 指引读者阅读 docs/development/testing.md 获取完整的测试设置与运行技巧。结合该文档Dokku 的测试体系由三部分组成Linter基于 shellcheck 的静态检查另有 shfmt 格式校验与 Go 插件的 golangci-lint功能单元测试基于 Bats 测试框架测试文件位于 tests/unit如apps_1.bats、config.bats等以.bats结尾公共辅助逻辑集中在 tests/unit/test_helper.bash其中定义了DOKKU_DOMAINdokku.me等测试常量与全局 setup/teardown 清理逻辑应用部署测试部署 tests/apps 下覆盖主流语言与框架的示例应用验证端到端部署能力。CI 环境所有 PR 都会在 CIUbuntu Noble 24.04、提供 Docker 支持上执行测试。若某次提交确实无需测试例如纯文档改动可在提交信息中加入[ci skip]标记但本应测试却携带该标记的提交不会被合并。这也侧面印证了测试门禁的强制性。本地执行环境Vagrant VM按 docs/getting-started/install/vagrant.md 搭建 Dokku VM 后执行vagrant ssh sudo su - cd ~/dokku make ci-dependencies setup-deploy-testsVSCode Dev Container在 DevContainer 的终端中直接执行同样的make ci-dependencies setup-deploy-tests。修改本地 Dokku 克隆后别忘了同步到 Vagrant 中的 Dokku 安装# 从本地 git 克隆更新 vagrant dokku 安装 make copyfiles # 单独构建某个插件 make go-build-plugin copyplugin PLUGIN_NAMEapps常用测试命令# 运行完整测试套件linter bats 单元测试 应用部署测试 make test # 仅运行 linter make lint # 仅运行全部 bats 单元测试 make unit-tests # 仅运行全部应用部署测试 make deploy-tests定向运行测试运行单个应用部署测试使用形如make deploy-test-nodejs-express的目标完整的部署测试目标列表位于仓库根目录 tests.mk例如deploy-test-dockerfile、deploy-test-python-flask、deploy-test-go、deploy-test-main-branch等运行单个测试套件当只改动某个插件时可指定套件路径例如bats tests/unit/apps_1.bats这套先本地、后 CI的验证闭环与上一节的分支、提交规范共同构成了 Dokku 贡献流程的质量保障体系规范的提交历史 可自动验证的编码标准 必须通过的测试门禁三者缺一不可。附加资源编码规范Dokku coding standardsbashstyle 风格约定现有 issue 列表用于检索重复问题、了解开放任务测试文档完整的测试设置说明与运行技巧Issue 模板提交报告时的必填字段清单测试基础设施linter、单元测试与部署测试的全部 make 目标。无论你是首次接触 Dokku 的新贡献者还是准备为某个插件提交修复的资深用户遵循上述流程都能让你的贡献更顺畅地被评审与合并——这也正是开源协作中让维护者省心的最佳实践。【免费下载链接】dokkuA docker-powered PaaS that helps you build and manage the lifecycle of applications项目地址: https://gitcode.com/GitHub_Trending/do/dokku创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考