ait-core 2.5.2

Tox

使用 tox 运行全面的工具构建，它会检查不同 Python 版本下的测试执行情况，验证文档构建，运行 linting 流程，并检查仓库包是否干净。确保您在没有其他虚拟环境激活的情况下在 Poetry 的 shell 中运行 tox，以避免 tox 为测试查找不同 Python 版本时出现问题。您可以使用以下命令运行所有开发工具：

tox

您可以通过传递 -l 来查看可用的 tox 测试环境，并通过传递其名称到 -e 来执行特定的一个。运行 tox -h 以获取更多信息。

测试

使用 pytest 手动运行测试套件

pytest

或通过 tox 运行特定 Python 版本的测试

tox -e py310

代码检查

我们在代码库上运行 black、flake8、mypy 和几个其他小检查器。我们的 linting 和代码检查流程在您提交或推送时运行。如果您想手动运行，可以使用以下命令：

pre_commit run --color=always {posargs:--all}

工具的单独调用配置在 .pre-commit-config.yaml 中。如果您想单独运行某个工具，您可以在那里看到我们如何调用它们。

您也可以使用 tox 运行所有 linting 工具。

tox -e lint

文档

AIT 使用 Sphinx 构建其文档。您可以使用以下命令构建文档：

poetry run build_sphinx

在网页浏览器中打开 doc/build/html/index.html 来查看文档。如果您只想检查文档构建是否正常工作，您可以使用 tox。

tox -e docs

如果您需要更新自动生成的文档，可以运行以下命令来重新构建所有包文档：

sphinx-apidoc --separate --force --no-toc -o doc/source ait --implicit-namespaces

请确保在票证中的更改导致文档过时时更新文档。

问题跟踪

所有更改都必须针对一个或多个票证进行，以便跟踪。AIT 使用 GitHub Issues 和 Zenhub 一起跟踪项目中的问题。所有票证都应该有（除了一些罕见的边缘情况外）

• 一个简洁的标题

• 对问题/请求的深入描述。如果您正在报告一个错误，描述应包括如何重现错误的说明。还应包括您看到错误的代码版本。

如果您打算开始处理一个票证，请确保根据适用性通过各种流程步骤推进票证，并指派自己为 Assignee。如果您缺乏足够的权限这样做，您可以在票证上发帖请求完成上述操作。

提交信息

AIT 项目采用了一种相当标准的提交信息格式化方法。您可以从 Tim Pope 的博客开始，了解如何格式化您的提交信息。所有提交信息都应该在其标题/摘要行中引用一个票证。

Issue #248 - Show an example commit message title

这确保了在 GitHub 上更新的票证中包含与提交相关的引用。

提交应该是原子的。尽可能保持解决方案的隔离。例如，“清理空白”或“修复错别字”之类的填充提交应在拉取请求之前进行变基。请确保您的提交历史是干净且有意义的！

代码格式化和风格

AIT 尽力遵守 PEP-8 规范。这由 black 自动执行，并由 flake8 检查。您应该对您所做的任何更改运行 pre-commit linting 流程。

测试

我们尽力确保所有变更都经过测试。如果你在修复错误，应该始终有一个伴随的单元测试，以确保我们不会回归！

请查看下面的开发者技巧部分，以获取有关运行每个存储库测试套件的信息。

拉取请求和功能分支

所有变更应隔离到一个功能分支，该分支链接到一个问题。在 AIT 项目中，标准做法是使用 issue-### 作为分支名称，其中 ### 是在 GitHub 上找到的问题编号。

拉取请求的标题应包括对要修复的问题的引用，正如提交消息中所述。拉取请求的描述应提供关于现有变更的深入解释。注意，如果你编写了良好的提交消息，这一步应该很容易！

任何由拉取请求解决的票证应使用 GitHub 关闭票证的语法进行引用。假设上述票证，我们在拉取请求描述中将具有以下内容

变更必须由 AIT PMC/Comitters 群组的至少一名成员进行审查，测试必须通过，分支必须与 master 保持同步，然后才能合并变更。如果作为代码审查的一部分进行变更，请确保清理您的提交历史。