贡献到 Ansible-lint¶
要为 ansible-lint 做贡献，请使用您自己 fork 的分支上的 pull request。
在GitHub 上创建您的 fork之后，您可以执行以下操作
$ git clone --recursive git@github.com:your-name/ansible-lint
$ cd ansible-lint
$ # Recommended: Initialize and activate a Python virtual environment
$ pip install --upgrade pip
$ pip install -e '.[test]' # Install testing dependencies
$ tox run -e lint,pkg,docs,py # Ensure subset of tox tests work in clean checkout
$ git checkout -b your-branch-name
# DO SOME CODING HERE
$ tox run -e lint,pkg,docs,py # Ensure subset of tox tests work with your changes
$ git add your new files
$ git commit -v
$ git push origin your-branch-name
然后，您可以根据您的提交创建 pull request。
所有对核心功能的修复（即除了文档或示例之外的任何内容）都应附带测试，这些测试在您更改之前失败，之后成功。
如果您觉得无法贡献代码修复，请随时在仓库中提出问题。
标准¶
ansible-lint 仅适用于其发布时受支持的 Ansible 版本。
所有 PR 都将运行自动化测试，要在推送提交之前在本地运行检查，只需使用tox。
联系我们¶
与 Ansible 社区联系！
加入 Ansible 论坛，提出问题，获得帮助并与社区互动。
- 获取帮助：获得帮助或帮助他人。如果您启动新的讨论，请添加相应的标签，例如使用
ansible-lint或devtools标签。 - 社交空间：与志同道合的爱好者见面和互动。
- 新闻和公告：跟踪项目范围内的公告，包括社交活动。
要获取来自社区的版本发布公告和重要更改，请参阅Bullhorn 新闻通讯。
要获得实时聊天体验，请加入#devtools:ansible.com Matrix 房间。
您可以在Ansible 通信指南中找到更多信息。
可能的安全性漏洞应通过电子邮件报告给security@ansible.com。
行为准则¶
与所有 Ansible 项目一样，我们有行为准则。
模块依赖关系图¶
考虑添加任何依赖项时，应格外小心。希望删除对 Ansible 内部结构的大多数依赖项，因为这些依赖项可能会在没有任何警告的情况下发生更改。
uv pip tree --package ansible-lint --show-version-specifiers --strict
Using Python 3.11.10 environment at: .tox/docs
ansible-lint v24.12.3.dev5
├── ansible-compat v24.10.0 [required: >=24.10.0]
│ ├── ansible-core v2.18.1 [required: >=2.14]
│ │ ├── cryptography v44.0.0 [required: *]
│ │ │ └── cffi v1.17.1 [required: >=1.12]
│ │ │ └── pycparser v2.22 [required: *]
│ │ ├── jinja2 v3.1.5 [required: >=3.0.0]
│ │ │ └── markupsafe v3.0.2 [required: >=2.0]
│ │ ├── packaging v24.2 [required: *]
│ │ ├── pyyaml v6.0.2 [required: >=5.1]
│ │ └── resolvelib v1.0.1 [required: >=0.5.3, <1.1.0]
│ ├── jsonschema v4.23.0 [required: >=4.6.0]
│ │ ├── attrs v24.3.0 [required: >=22.2.0]
│ │ ├── jsonschema-specifications v2024.10.1 [required: >=2023.3.6]
│ │ │ └── referencing v0.35.1 [required: >=0.31.0]
│ │ │ ├── attrs v24.3.0 [required: >=22.2.0]
│ │ │ └── rpds-py v0.22.3 [required: >=0.7.0]
│ │ ├── referencing v0.35.1 [required: >=0.28.4] (*)
│ │ └── rpds-py v0.22.3 [required: >=0.7.1]
│ ├── packaging v24.2 [required: *]
│ ├── pyyaml v6.0.2 [required: *]
│ └── subprocess-tee v0.4.2 [required: >=0.4.1]
├── ansible-core v2.18.1 [required: >=2.13.0] (*)
├── black v24.10.0 [required: >=24.3.0]
│ ├── click v8.1.8 [required: >=8.0.0]
│ ├── mypy-extensions v1.0.0 [required: >=0.4.3]
│ ├── packaging v24.2 [required: >=22.0]
│ ├── pathspec v0.12.1 [required: >=0.9.0]
│ └── platformdirs v4.3.6 [required: >=2]
├── filelock v3.16.1 [required: >=3.3.0]
├── importlib-metadata v8.5.0 [required: *]
│ └── zipp v3.21.0 [required: >=3.20]
├── jsonschema v4.23.0 [required: >=4.10.0] (*)
├── packaging v24.2 [required: >=21.3]
├── pathspec v0.12.1 [required: >=0.10.3]
├── pyyaml v6.0.2 [required: >=5.4.1]
├── ruamel-yaml v0.18.6 [required: >=0.18.5]
│ └── ruamel-yaml-clib v0.2.12 [required: >=0.2.7]
├── subprocess-tee v0.4.2 [required: >=0.4.1]
├── wcmatch v10.0 [required: >=8.1.2]
│ └── bracex v2.5.post1 [required: >=2.1.1]
└── yamllint v1.35.1 [required: >=1.30.0]
├── pathspec v0.12.1 [required: >=0.5.3]
└── pyyaml v6.0.2 [required: *]
(*) Package tree already displayed
添加新规则¶
编写新规则就像添加单个新规则一样简单，该规则结合了**实现、测试和文档**。
一个很好的例子是MetaTagValidRule，通过遵循以下步骤，可以轻松复制它以创建一个新规则
- 使用简短但清晰的类名，它必须与文件名匹配
- 选择一个未使用的
id，第一个数字用于确定规则部分。查看规则页面并选择一个最匹配您的新规则的页面，并查看哪个最适合。 - 包含
experimental标签。任何新规则必须至少保持两周为实验性，直到在下一个主要版本中删除此标签。 - 更新所有类级别变量。
- 实现您的规则所需的 lint 方法，这些方法以**match**前缀开头。仅实现您需要的那些方法。目前，您需要查看类似规则是如何实现的，以弄清楚该怎么做。
- 更新测试。它必须至少有一个测试，并且可能还有一个负匹配测试。
- 如果规则是特定于任务的，最好也包含一个测试来验证其在块内的使用情况。
- 可以选择仅使用类似以下命令运行特定于规则的测试：
tox -e py -- -k NewRule - 运行
tox以运行所有 ansible-lint 测试。添加新规则可能会破坏其他一些测试。如有需要，请更新它们。 - 运行
ansible-lint -L并检查规则说明是否正确呈现。 - 使用
tox -e docs构建文档，并检查新规则是否在文档中正确显示。
文档变更¶
要构建文档，请运行tox -e docs。在构建结束时，您将看到已构建文档的本地位置。
本地构建文档可能与 CI/CD 构建不完全相同。我们建议您创建一个草稿 PR 并检查 RTD PR 预览页面。
如果您不想学习 reStructuredText 格式，您也可以提交问题，并让我们知道如何改进我们的文档。