ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Celery 贡献指南:从 Bug 报告、代码规范到发布流程的完整实践手册

2026/9/19 17:01:59 拓冰建站 浏览量
Celery 贡献指南:从 Bug 报告、代码规范到发布流程的完整实践手册 任务调度后端消息队列【免费下载链接】celeryDistributed Task Queue (development branch)项目地址https://gitcode.com/gh_mirrors/ce/celery点击查看免费下载Celery 是一个用 Python 编写的分布式任务队列Distributed Task Queue其核心价值在于把耗时任务从 Web 请求中剥离出来交给独立的 Worker 进程异步执行。本文基于仓库根目录的 CONTRIBUTING.rst在文档体系中由 docs/contributing.rst 引用撰写系统梳理 Celery 官方为贡献者提供的完整协作流程如何正确报告安全漏洞与普通 Bug、如何 Fork 并搭建本地开发环境、如何使用 Docker 与 pytest 运行测试、如何提交符合规范的 Pull Request以及新功能附带第三方依赖时应遵循的工程流程。读完本文你将掌握一套可落地的开源协作方法论既能按官方标准提交高质量 Issue也能在自己的分支上完成编码、测试、静态检查、文档校验的完整闭环还能理解 Celery 版本分支与发布节奏从而让你的贡献更快被维护者接受。参与贡献前的核心原则Celery 官方在 CONTRIBUTING.rst 开篇就强调贡献必须简单社区必须友好不纠结细枝末节的编码风格。这是整个贡献流程的基调。对于小型贡献无需通读整份指南模仿你正在修改的代码周围的既有约定即可所有补丁最终都会由合并者清理因此不必过度焦虑格式问题报 Bug 前务必阅读下文「Reporting Bugs」一节确保报告包含足够信息提代码前尽量模仿周边代码的写法并遵循下文「Coding Style」的约定。社区行为准则Code of ConductCelery 社区以维护一个多元、愉悦的社区为目标行为准则覆盖所有交流场景论坛、邮件列表、Wiki、网站、IRC 聊天室、公开会议或私人通信。其内容参考了 Ubuntu Code of Conduct 与 Pylons Code of Conduct核心精神包括Be considerate体谅他人你的工作会被他人使用你也会依赖他人的工作。任何决定——代码、基础设施、政策、文档或翻译——都可能影响他人。Be respectful互相尊重团队成员相互尊重分歧不是失礼的借口。Be collaborative乐于协作协作是 Celery 与自由软件社区的核心工作应透明进行。When you disagree, consult others有分歧时求助他人用建设性的方式、借助社区流程解决分歧若坚持走自己的路线鼓励基于现有工作制作衍生发行版。When youre unsure, ask for help不确定时主动提问提问能避免许多后续问题被提问者应积极响应。Step down considerately体面退出离开项目时应尽量减少对项目的干扰告知他人并确保交接顺畅。Reporting Bugs如何写出有效的问题报告安全漏洞必须走私密渠道安全相关问题漏洞、包含敏感信息的问题绝不能提交到公开的 Issue 追踪器或任何公开场合而必须发送邮件至securityceleryproject.org。需要加密时可以使用文档中给出的 PGP 公钥见 CONTRIBUTING.rst 中的BEGIN PGP PUBLIC KEY BLOCK块。普通 Bug 的六步提交流程非安全类问题的最佳途径是 Issue 追踪器官方给出六步流程创建 GitHub 账号这是创建 Issue 和参与讨论的前提。判断是否为真正的 Bug若你只是寻求支持应使用邮件列表或 IRC 频道确需在 GitHub 提问时请在标题前加[QUESTION]前缀。确认 Bug 尚未被报告先搜索 Issue 追踪器若已有类似报告补充自己掌握的新信息比重复提交更有价值。确认使用的是最新版本Bug 可能已被其他改进修复请确保 celery、billiard、kombu、amqp、vine 这些核心包都是最新版本。关于版本号的语义参见下文「版本与分支」。收集 Bug 信息这是决定修复效率的关键环节A若是 Python 回溯traceback错误把完整回溯贴进报告B说明运行平台Windows、macOS、Linux 等、Python 解释器版本以及出错时 Celery 及相关包的版本C若是竞态条件race condition或死锁deadlock回溯往往难以获取或参考价值有限可尝试进程诊断启用 Celery 的断点信号breakpoint signal并用它打开pdb会话检查进程状态用straceLinux、dtrussmacOS、ktraceBSD、ltrace、lsof收集系统调用与文件句柄层面的追踪数据D附上celery report命令输出它会把你的配置设置一并带出并尝试剔除已知敏感键的值——但提交前仍需人工核对确保不含 API Token、认证凭据等机密信息$ celery -A proj reportE若你的 Issue 被打上Needs Test Case标签意味着需要提供可复现的最小代码或详细的复现指令与配置值。提交 BugGitHub 默认会在有新评论时邮件通知若关闭了该功能请定期回访以免错过维护者提出的追问。各生态包的问题归属Celery 生态中各包有独立的 Issue 追踪器celery、kombu消息库、amqpPython AMQP 0.9.1 客户端、vinePromise/deferred 实现、pytest-celeryPytest 插件、librabbitmqC 语言编写的快速 AMQP 客户端、django-celery-beat、django-celery-results。若不确定问题归属可先在邮件列表询问或直接使用 Celery 主仓库的追踪器。完整包清单与联系信息见 CONTRIBUTING.rst 的「Contacts」「Packages」两节。版本号、分支与标签理解 Celery 的发布节奏版本号语义自 2.1.0 起Celery 遵循 SemVer语义化版本规范版本号由主版本号、次版本号、修订号组成。稳定版发布到 PyPI开发版仅以 Git 标签形式存在于仓库所有版本标签以v开头——例如 0.8.0 对应标签v0.8.0。分支结构当前处于活跃状态的分支包括main即 git 所称的 dev 分支、4.5、3.1。分支状态可通过 Changelog.rst 顶部的元数据判断4.3.0 :release-date: TBA :status: DEVELOPMENT :branch: dev (git calls this main)其中status字段有三种取值PLANNING分支处于实验与规划阶段DEVELOPMENT活跃开发中但测试套件应保持通过、产品可用且可供用户测试FROZEN分支冻结不再接受新特性聚焦于发布前的充分测试。分支的命名与生命周期规则如下dev/main 分支下一个版本在此开发维护分支Maintenance branches以版本号命名如 2.2.x 系列对应2.2早期曾用releaseXX-maint命名归档分支Archived branches仅保留历史理论上可为不再官方支持的系列提交补丁命名为X.Y-archived。仓库当前没有任何归档版本特性分支Feature branches大型新特性在专用分支开发命名无严格约束合并进发布分支后即删除。标签规则标签仅用于标记发布格式为vX.Y.Z如v2.3.1实验性发布带附加标识如v3.0.0-rc1实验性标签可能在正式发布后被移除。搭建开发环境Fork 与分支管理Fork 并配置 upstream先在 GitHub 上 Fork Celery 仓库然后克隆到本地$ git clone gitgithub.com:username/celery.git $ cd celery $ git remote add upstream gitgithub.com:celery/celery.git $ git fetch upstream之后从 upstream 拉取新变更时务必使用--rebase避免用 merge 提交污染历史$ git pull --rebase upstream main需要基于远程分支工作时可这样检出$ git checkout --track -b 5.0-devel upstream/5.0-devel注意任何特性分支或修复分支都应从upstream/main创建。使用 Docker 开发与测试Celery 由 broker、backend 等众多组件构成官方推荐用 Docker 与 docker-compose 大幅简化开发测试循环。相关组件位于 docker/ 目录镜像通过PYTHON_IMAGE构建参数参数化使用对应的官方 Python 或 PyPy 基础镜像。Compose 服务与 Python 版本docker/docker-compose.yml 为每个受支持的 Python 版本定义一个服务celery311Python 3.11celery312Python 3.12celery313Python 3.13celery314Python 3.14celerypypy311PyPy 3.11该文件同时定义了TEST_BROKER、TEST_BACKEND等环境变量并挂载 RabbitMQ、Redis、DynamoDB、Azurite 等服务见depends_on配置用于支撑集成测试。构建与运行命令构建全部镜像$ make docker-build只构建某个 Python 版本$ docker compose -f docker/docker-compose.yml build celery312在容器内执行命令--rm表示容器退出后自动删除避免堆积无用容器$ docker compose -f docker/docker-compose.yml run --rm celery312 command常用命令示例$ docker compose -f docker/docker-compose.yml run --rm celery312 bash $ docker compose -f docker/docker-compose.yml run --rm celery312 pytest t/unit $ docker compose -f docker/docker-compose.yml run --rm celery312 pytest t/integration换 Python 版本只需替换服务名如celery311、celery313、celery314、celerypypy311。直接构建 Dockerfile通过PYTHON_IMAGE构建参数可指定任意基础镜像默认值为python:3.14-slim-bookworm与 docker/Dockerfile 顶部ARG声明一致$ docker build \ --build-arg PYTHON_IMAGEpython:3.12-slim-bookworm \ -f docker/Dockerfile .源码挂载与自定义项目调试默认情况下 Docker Compose 会把 Celery 源码树挂载进容器代码改动立即可见同时通过设置PYTHONPATH/home/developer/celery让挂载的代码以全局模块方式被使用python -m pip install -e .是等效的开发模式安装方式。要手动调试自己的 Django 或独立项目可复用仓库构建的镜像并挂载自定义代码。假设目录结构为 celery_project celery # 仓库克隆于此 my_project - manage.py my_project - views.py对应的 docker-compose 配置services: celery312: image: celery/celery:dev-py312 environment: TEST_BROKER: amqp://rabbit:5672 TEST_BACKEND: redis://redis volumes: - ../../celery:/home/developer/celery - ../my_project:/home/developer/my_project depends_on: - rabbit - redis rabbit: image: rabbitmq:latest redis: image: redis:latest运行单元测试套件安装依赖不使用 Docker、改用虚拟环境开发时需安装依赖。仓库提供了多个 requirements 文件requirements/default.txt是必装的$ pip install -U -r requirements/default.txt运行测试套件还需安装 requirements/test.txt$ pip install -U -r requirements/test.txt $ pip install -U -r requirements/default.txt执行测试$ pytest t/unit $ pytest t/integration常用 pytest 选项-x在第一个失败测试处停止-s不捕获输出-v详细输出。只跑单个测试文件$ pytest t/unit/worker/test_worker.py仓库的测试目录结构与本命令一一对应t/unit/下按模块分子目录如t/unit/worker/、t/unit/backends/、t/unit/app/t/integration/与t/smoke/分别承载集成与冒烟测试。计算测试覆盖率先安装 pytest-cov$ pip install -U pytest-covHTML 格式覆盖率输出到htmlcov/目录可用浏览器打开htmlcov/index.html$ pytest --covcelery --cov-reporthtml $ open htmlcov/index.htmlXMLCobertura 风格格式覆盖率输出到coverage.xml$ pytest --covcelery --cov-reportxml用 tox 在所有受支持 Python 版本上运行测试仓库根目录的 tox.ini 配置了完整的 tox 环境矩阵unit、integration 各后端组合、smoke、flake8、apicheck、configcheck、bandit 等。运行全部环境$ tox只测特定版本$ tox -e 3.7构建文档本地构建安装文档依赖 requirements/docs.txt 与 requirements/default.txt$ pip install -U -r requirements/docs.txt $ pip install -U -r requirements/default.txt如需无警告构建还需安装 LaTeX 相关工具$ apt-get install texlive texlive-latex-extra dvipng然后构建$ cd docs $ rm -rf _build $ make html构建输出中不应有错误或警告成功后文档位于docs/_build/html。文档的构建入口是 docs/Makefilemake html、make apicheck等目标Sphinx 配置见 docs/conf.py。用 Docker 构建并实时预览$ docker compose -f docker/docker-compose.yml up --build docsdocs服务会启动本地文档服务器端口映射见 docker/docker-compose.yml 中ports: 7001:7000基于sphinx-autobuild并开启--watch可实现文档的实时编辑预览。验证你的贡献验证工具依赖在 requirements/pkgutils.txt$ pip install -U -r requirements/pkgutils.txtpyflakes 与 PEP-8确保改动符合 PEP 8 并可通过 pyflakes$ make flakecheck若不想让失败返回负退出码如用于脚本判断改用flakes目标$ make flakes对应实现见 Makefile 的flakecheck/flakediag/flakes目标实际执行flake8 celery t。API 参考完整性检查确保所有模块在 API 参考中都有对应章节$ make apicheck若缺文件可复制现有参考文件为模板。内部模块应放在 docs/internals/reference/公开模块放在 docs/reference/。以新增公开模块celery.worker.awesome为例$ cd docs/reference/ $ cp celery.schedules.rst celery.worker.awesome.rst $ vim celery.worker.awesome.rst # 把所有 celery.schedules 替换为 celery.worker.awesome $ vim index.rst # 把 celery.worker.awesome 加进索引 $ git add celery.worker.awesome.rst $ git add index.rst $ git commit celery.worker.awesome.rst index.rst \ -m Adds reference for celery.worker.awesomeisort 导入排序Celery 用 isort 维护每个模块的导入顺序新增模块或改动导入时请运行$ isort my_module.py # 处理单个文件 $ isort -rc . # 递归处理整个目录 $ isort m_module.py --diff # 干跑查看建议改动创建 Pull Request 前的自查清单提交 PR 前逐项核对以下清单与 .pre-commit-config.yaml 及 tox.ini 中配置的检查项一一对应可显著提高被合入的概率测试任何改动或新特性都应有单元和/或集成测试。若未写测试PR 会被贴上Needs Test Coverage标签。覆盖率不下降运行pytest -xv --covcelery --cov-reportxml --cov-report term确认覆盖率。pre-commit以下命令等价pre-commit run --all-files或tox -e lint。仓库的 pre-commit 钩子包含 pyupgrade、flake8、yesqa、codespell、check-merge-conflict、check-toml、check-yaml、mixed-line-ending、isort、mypy。API 文档检查以下命令等价make apicheck、cd docs sphinx-build -b apicheck -d _build/doctrees . _build/apicheck或tox -e apicheck。配置检查以下命令等价make configcheck、cd docs sphinx-build -b configcheck -d _build/doctrees . _build/configcheck或tox -e configcheck。安全扫描以下命令等价pip install -U bandit后bandit -b bandit.json celery/或tox -e bandit。仓库根目录的 bandit.json 为基线配置。全 Python 版本测试tox -v。isort 确认isort my_module.py --diff。Status 标签的含义维护者会用带Status:前缀的标签标注 Issue/PR 状态常见含义如下标签含义Status: Cannot Reproduce核心团队成员无法复现该问题Status: Confirmed已被至少一位核心团队成员确认Status: Duplicate重复的 Issue 或 PRStatus: Feedback Needed维护者正在征求反馈Status: Has Testcase已确认包含测试用例Status: In ProgressPR 仍在进行中Status: Invalid对项目无效Status: Needs DocumentationPR 缺少对应文档Status: Needs RebasePR 未与main变基合并前必须 rebase 以解决冲突Status: Needs Test Coverage需要补充测试以维持覆盖率Status: Needs Test Case需要最小可复现代码或详细复现步骤Status: Needs Verification需要验证报告者提供的测试用例或将其纳入集成套件Status: Not a Bug已判定非 BugStatus: Wont Fix决定不予修复但欢迎外部贡献者帮助解决Status: Works For Me核心成员确认问题在其环境下可正常工作此外还有Component:canvas这类组件标签用于标明 Issue/PR 对应的功能模块canvas 即任务编排画布。Coding Style编码规范速查所有 Python 代码必须遵循 PEP 8docstring 遵循 PEP 257具体约定如下Docstring 风格推荐以下两种写法def method(self, arg): Short description. More details. def method(self, arg): Short description.而不要写成def method(self, arg): Short description. 行长限制行不应超过78 列78 为软限制79 为硬限制。Vim 用户可设置set textwidth78导入顺序按以下分组组内按模块名排序Python 标准库import xxxPython 标准库from xxx import第三方包当前包的其他模块使用 Django 的代码额外插入一组「Django 包」位于第三方包之后。示例import threading import time from collections import deque from Queue import Queue, Empty from .platforms import Pidfile from .utils.time import maybe_timedelta其他约定禁止通配导入from xxx import *支持 Python 2.5 及更老版本的发行版另有额外规则如每个模块顶部启用from __future__ import absolute_import、每个 future import 独占一行等——Celery 本身不受此约束因为其python_requires3.10见 setup.py使用「新式」相对导入from . import submodule。为需要额外库的特性贡献代码某些特性如新的结果后端需要用户额外安装第三方库Celery 用 setuptools 的extras_require管理这些可选依赖新特性必须按以下三步接入对应实现见 setup.py 中的extras()与extras_require()函数以及 requirements/extras/ 目录——其中已包含 arangodb、cassandra、redis、s3、mongodb 等 38 个后端/组件的 extras 文件1在requirements/extras新增需求文件。以 Cassandra 后端为例文件 requirements/extras/cassandra.txt 内容pycassa这是 pip 需求文件支持版本限定符多个包以换行分隔。更复杂的例子# pycassa 2.0 breaks Foo pycassa1.0,2.0 thrift2修改setup.py把新文件加入extras_requireextra[extras_require] { # ... cassandra: extras(cassandra.txt), }3在 docs/includes/installation.txt 的 bundles 一节补充文档。改完后渲染发行版 README$ pip install -U -r requirements/pkgutils.txt $ make readme额外要求若特性新增配置选项必须在 docs/configuration.rst 中说明并且所有设置都要添加到 celery/app/defaults.py这是 Celery 配置项的唯一权威来源解析逻辑见 celery/app/defaults.py 的命名空间结构结果后端还需要在docs/configuration.rst中单独开一节。发布流程从版本号到 PyPI更新版本号版本号需在三处更新celery/init.py、docs/include/introduction.txt、README.rst。可用bumpversion工具统一处理$ bumpversion之后渲染 README用脚本把 sphinx 语法转为通用 reStructuredText对应 Makefile 的readme目标$ make readme提交并打标签$ git commit -a -m Bumps version to X.Y.Z $ git tag vX.Y.Z $ git push --tags发布稳定版$ make distcheck # 检查 pep8、autodoc 索引、运行测试等 $ make dist # 注意会执行 git clean -xdf删除仓库中未跟踪的文件 $ python setup.py sdist upload --sign --identityCelery Security Team $ python setup.py bdist_wheel upload --sign --identityCelery Security Team若属于新发布系列还需在 Read The Docs 管理界面把默认分支切到该系列分支并在 versions 标签页添加上一版本。联系与资源遇到问题时优先 报告 Issue非紧急问题可联系维护者。仓库维护者包括 Ask Solem、Asif Saif Uddin、Dmitry Malinovsky、Ionel Cristian Mărieș、Mher Movsisyan、Omer Katz、Steeve Morin、Josue Balandrano Coronel、Tomer Nosrati 等。核心仓库与配套包kombu、amqp、vine、billiard、pytest-celery、django-celery-beat、django-celery-results、librabbitmq 等的 git/PyPI/CI 地址均在 CONTRIBUTING.rst 的「Packages」一节列出已废弃的包如 django-celery、Flask-Celery、celerymon、carrot、ghettoq 等也在「Deprecated」一节中说明。总结本文完整覆盖了 Celery 官方贡献指南的各个层面社区行为准则、安全漏洞与普通 Bug 的报告规范、版本分支体系、Fork 与 Docker 开发环境、单元/集成测试与覆盖率、文档构建、PR 提交前的全套校验flake8、apicheck、configcheck、bandit、isort、pre-commit、编码规范、可选依赖特性的接入流程以及最终发布流程。核心配置文件均可直接在仓库中查阅验证Docker 编排见 docker/docker-compose.yml、测试矩阵见 tox.ini、构建目标见 Makefile、lint 钩子见 .pre-commit-config.yaml。无论你是首次提交的小型贡献者还是计划深入内核的长期维护者这套流程都能让协作更顺畅、变更更快被接受。赞分享任务调度后端消息队列【免费下载链接】celeryDistributed Task Queue (development branch)项目地址https://gitcode.com/gh_mirrors/ce/celery点击查看免费下载相关推荐Celery 贡献者完全指南从 Bug 报告、Docker 开发环境到代码规范与发布流程Celery 贡献者完全指南从 Bug 报告、Docker 开发环境到代码规范与发布流程 CeleryDistributed Task Queue是一套成任务调度后端消息队列3步导出微信聊天记录WeChatMsg数据备份与年度报告生成完整指南3步导出微信聊天记录WeChatMsg数据备份与年度报告生成完整指南 换手机或重装系统时大家都会仔细迁移照片和通讯录却常常忘了微信聊天记录还锁在旧手机里。spaCy 贡献者指南从 Issue 报告、源码构建到测试与代码规范的完整实践手册spaCy 贡献者指南从 Issue 报告、源码构建到测试与代码规范的完整实践手册 导读 本文是 spaCyPython 工业级自然语言处理库官方贡献指南人工智能NLP机器学习预训练创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考