Ansible 社区软件包集合要求

概述

本文档描述了包含在 Ansible 社区软件包中的 Ansible 社区集合维护者的要求。所有包含候选者和已包含的集合都必须满足本文档中标有MUST的标准。

您还可以在集合包含标准检查清单上找到这些要求。

每个被拒绝的候选者都将根据在专用社区主题中做出的决定，从Ansible 社区指导委员会获得反馈。

反馈和沟通

任何反馈和帮助都非常受欢迎。请创建一个社区主题或将您的问题带到社区会议。

保持知情

跟踪影响集合的变化

沟通和工作组

论坛概述

论坛是我们异步的默认通信平台。

在组织围绕 Ansible 集合的沟通方面，您需要了解以下概念

  • 标签：与类别一起，标签是论坛中用于组织围绕特定主题的对话的主要功能。大多数 Ansible 项目都具有一个或多个关联标签。对于 Ansible 集合，主要标签名称通常是集合目标的技术：例如，kubernetes.core 的 kubernetes，ansible.windows 的 windows 以及 community.postgresql 的 postgresql。

  • 论坛组：组允许您组织用户、管理权限、拥有提供相关信息的组工作页面、自动将成员订阅到标签、提及或向整个组发送消息等等。一个集合工作组示例是PostgreSQL Ansible 集合工作组。

有关更多详细信息，请参阅工作组 - 您可以请求的事项！论坛主题。

沟通要求

您的集合

  • 必须在论坛中具有相应的公共标签，或至少重用一个现有标签。

    • 如果多个集合涵盖类似的主题，则可以共享一个标签；例如，amazon.aws 和 community.aws 都可以使用标签 aws。

    • 此外，集合可以请求论坛组。如果集合请求或已拥有组

      • 所有相关标签必须与该组关联。加入该组的每个人都会自动订阅这些标签。

      • 该组必须是公开的，并且任何论坛用户都可以自由加入。

    • 使用请求标签/论坛组主题来请求标签和论坛组。

  • 必须在其 README 中包含一个通信部分，其中包含对论坛的引用，类似于collection_template README.md。

    • 该部分必须至少包含对获取帮助论坛类别的引用，可能包括 URL 中的标签。

    • 该部分必须包含有关参与者应为与集合相关的主题使用哪些标签的信息。

    • 如果集合有论坛组，则该部分必须包含对该组的引用。

    • 引用的描述必须欢迎读者加入和参与。

    • 集合的维护者应该订阅所有关联的标签，并且是所有关联组的成员。

  • 应该禁用 GitHub 的Discussions功能，转而使用论坛。

集合基础设施

以下指南描述了集合所需的基础设施

  • 必须有一个公开可用的问题跟踪器，该跟踪器不需要付费的服务级别来创建帐户以及创建和查看问题。

  • 必须在其存储库中启用问题功能，并接受任何人的问题报告。

  • 必须具有与社区行为准则兼容的行为准则 (CoC)。

  • 必须发布到Ansible Galaxy，版本为 1.0.0 或更高版本。

  • 必须仅包含遵循许可规则的对象。

  • 不应包含任何大型对象（二进制文件），与当前 Galaxy tarball 大小限制 20 MB 相比，例如，不要包含用于测试目的的软件包安装程序。

  • 不应包含任何不必要的文件，例如临时文件。

Python 兼容性

除了本节中指定的 Python 要求外，集合还**应该**遵循 ansible-and-python-3 中的提示。

Python 要求

集合的 Python 要求在**控制环境**和**其他环境**之间有所不同。

控制环境

  • 除非必需库不支持这些 Python 版本，否则集合**必须**支持控制环境中所有符合条件的控制器 Python 版本。 指导委员会 可以根据具体情况授予其他例外。

    • 控制环境：插件/模块始终在与 ansible-core 本身相同的环境（Python 解释器、venv、主机等）中运行。

    • 符合条件的控制器 Python 版本：控制器端至少由集合支持的一个 ansible-core 版本支持的 Python 版本。可以通过 ansible-core 支持矩阵 和集合中 meta/runtime.yml 文件中的 requires_ansible 值来确定符合条件的版本。

  • 集合**必须**记录控制环境中**不支持**的所有符合条件的控制器 Python 版本。有关详细信息，请参阅 Python 文档要求。

其他环境

  • 除非必需库不支持这些 Python 版本，否则集合**必须**支持其他环境中所有符合条件的控制器 Python 版本。 指导委员会 可以根据具体情况授予其他例外。

    • 其他环境：插件/模块不在控制环境中运行。

    • 符合条件的目标 Python 版本：目标端至少由集合支持的一个 ansible-core 版本支持的 Python 版本。可以通过 ansible-core 支持矩阵 和集合中 meta/runtime.yml 文件中的 requires_ansible 值来确定符合条件的版本。

  • 集合**必须**记录其他环境中不支持的所有符合条件的目标 Python 版本。有关详细信息，请参阅 Python 文档要求。

放弃 Python 版本支持

由于放弃对现有模块/插件的 Python 版本的支持属于重大更改，因此集合

  • **应该**在支持被放弃之前的先前版本中，在其更改日志的已弃用功能部分中宣布它。

  • **必须**发布一个实际上放弃支持的主版本。

Python 文档要求

  • 如果您的集合不支持所有符合条件的控制器/目标 Python 版本，则**必须**在 README 中记录它支持哪些版本。

  • 如果您的集合的大部分与 ansible-core 支持相同的 Python 版本，但某些模块和插件不支持，则**必须**在这些模块和插件的文档中包含支持的 Python 版本。

开发模块和插件实用程序的标准

  • module_utils 和 plugin_utils 可以标记为仅供集合内部使用，但**必须**记录这一点，并且**必须**对文件名使用前导下划线。

    • 如果将 module_utils 中的实用程序从公共更改为私有，则正在进行重大更改。如果这样做，则必须发布集合的新主版本。

  • 以下是 module_utils 文档的一些建议

    • 无文档字符串：我们推荐的所有 other-environment 都是支持的。

    • 文档字符串 'Python versions supported: same as for controller-environment'：我们推荐的所有 controller-environment 都是支持的。

    • 包含特定版本的文档字符串：'Python versions supported: '。

存储库结构要求

galaxy.yml

  • **必须**设置 tags 字段。

  • 集合依赖项**必须**满足一组规则。有关详细信息，请参阅关于 集合依赖项 的部分。

  • 如果您计划拆分集合，则在较小的集合替换 Ansible 中的较大集合之前，**必须**批准新的集合。

  • 如果您计划添加其他集合作为依赖项，则**必须**通过正式的申请流程。

README.md

您的集合存储库**必须**在集合的根目录中包含一个 README.md，有关示例，请参阅 collection_template/README.md。

meta/runtime.yml

示例：meta/runtime.yml

  • meta/runtime.yml **必须**使用 requires_ansible 字段定义此集合使用的 ansible-core 的最低版本。例如，如果集合与 ansible-core 2.16 及更高版本一起使用，则在 meta/runtime.yml 文件中设置 requires_ansible: '>=2.16'。

meta/execution-environment.yml

如果集合具有控制器端 Python 包和/或系统包要求，为了便于 执行环境 构建，**应该**在 meta 目录下的相应文件中列出它们，在 meta/execution-environment.yml 中指定，并 验证。

有关更多信息，请参阅 集合级依赖项指南，并以 collection_template/meta 目录内容为例。

模块和插件

  • 集合**必须**仅在 plugins/ 目录中使用下面指定的目录，并且仅用于列出的目的

    ansible-core 识别的：:

    doc_fragments、modules、module_utils、terminal，以及 使用插件 中列出的目录。可以通过查看 https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/loader.py#L1126 中每个 *_loader 的包参数的最后一个元素来验证此列表。

    plugin_utils:

    用于仅在控制器端使用的共享代码，不在模块中使用。

    sub_plugins:

    用于由集合内部而不是 ansible-core 管理的其他插件。我们使用子文件夹，这样当 ansible-core 添加新的插件类型时就不会发生冲突。

    核心团队（维护 ansible-core）承诺不会将这些目录用于任何与此处指定的用途冲突的内容。

其他目录

  • 集合**必须**不使用 meta/、plugins/、roles/ 和 playbooks/ 之外的任何文件，这些文件在任何可以通过 FQCN 调用、从其他集合使用或从用户剧本和角色使用的插件、角色或剧本中使用。

    • 如果从已安装的集合中删除除这四个目录及其内容之外的所有文件或目录，则集合**必须**能够正常工作。

    • 内部插件、角色和剧本（仅在测试中使用、仅用于发布集合或仅用于其他内部目的且不外部使用的人工制品）不受此规则限制，并且可能依赖于其他目录中的文件。

文档要求

集合

  • 必须使用 链接和格式化宏。

  • 应该在 CONTRIBUTING.md 或 README.md 文件中包含贡献者指南。

所有模块和插件

  • 必须包含 DOCUMENTATION 块。

  • 必须包含 EXAMPLES 块（除非与插件类型不相关）。

  • 必须在引用集合内部和外部的模块、插件和文档片段时使用 FQCN，包括对 ansible-core 使用 ansible.builtin.。

  • 必须为返回数据的模块和其他插件包含 RETURN 块。

  • 必须在将新内容添加到现有集合中时包含 version_added 字段，例如，对于模块、插件、选项、返回值和属性。

    • 在创建新集合之前，无需在第一个版本发布之前添加 version_added。

    • 集合中对象的 version_added 字段**必须**引用添加选项的集合版本 - **不**是 Ansible 或 ansible-core 的版本。

      • 如果由于某种原因需要指定 Ansible 或其他集合的版本号，则**必须**还提供 version_added_collection: collection_name。我们强烈建议**不要**这样做。

贡献者工作流

变更日志

  • 集合**必须**在正确的格式中包含变更日志。

    1. 您可以使用antsibull-changelog（文档）生成或检查变更日志，它为包含在ansible包中的集合提供变更日志的一致性。

版本控制和弃用

  • 集合**必须**遵守语义版本控制约定

    • **必须**在其集合根目录下的README.md文件中包含此信息。

    • **应该**在其贡献者和维护者文档中包含此信息。

    • **必须**在正确的类别下包含变更日志条目（Major changes、Minor changes、Bugfixes等）。

  • 集合**必须**保持向后兼容性

    • 为了保持用户的向后兼容性，每个 Ansible 次要版本系列 (x.Y.z) 将使集合的主版本保持不变。

      • 例如，如果 Ansible 3.0.0 包含community.general 2.2.0，则每个 3.Y.z (3.1.z、3.2.z 等) 版本将包含在构建时可用的最新community.general 2.y.z 版本。

      • Ansible 3.y.z **绝不会**包含community.general 3.y.z 版本，即使它可用。

      • 集合的主版本更改将包含在下一个 Ansible 主版本（在此示例中为 4.0.0）中。

      • 因此，请确保包含在 3.0.0 中的集合的当前主版本至少在生成新的 3.Y.Z 版本时接收错误修复。

    • 由于包含了新的次要版本，您可以包含新的功能、模块和插件。您**必须**确保您**不会**破坏向后兼容性！这意味着特别是

      • 您可以在patch releases中修复错误，但您**不得**添加新功能或弃用内容。

      • 您可以在minor releases中添加新功能和弃用内容，但您**不得**删除内容或更改现有功能的行为。

      • 您只能在major releases中删除内容或进行重大更改。

      • 有关更多信息，请参阅语义版本控制。

    • 我们建议您确保如果在包含在 Ansible 3.y.z 中的集合版本中添加了弃用，则删除本身只会发生在包含在 Ansible 5.0.0 或更高版本中，而不是包含在 Ansible 4.0.0 中的集合版本中。

  • 集合**应该**以某种方式向贡献者和用户提供其发布和弃用策略，例如，在其 README 或固定问题中。请参阅community.general 中的公告作为示例。

命名

集合命名

为全新的命名空间选择名称时

  • 请考虑命名空间限制，其中列出了 Galaxy 中命名空间的要求。

  • 如果命名空间尚不存在且未被其他人占用，请提交命名空间请求以创建它。

命名建议

  • 对于ansible-collections GitHub 组织下的集合，存储库**应该**命名为NAMESPACE.COLLECTION。

  • 对于创建用于处理特定实体的集合，它们应包含实体名称，例如community.mysql。

  • 对于公司维护的集合，存储库可以命名为COMPANY_NAME.PRODUCT_NAME，例如ibm.db2。

  • 避免 FQCN/存储库名称

    • 过长：尽量使其简洁明了。

    • 在NAMESPACE和COLLECTION部分包含相同的单词/词组，例如my_system.my_system。

注意

如果您计划在**Red Hat Automation Hub**上获得集合认证，请通过[email protected]咨询 Red Hat 合作伙伴工程，以确保**Galaxy**上的社区集合与认证集合之间的集合命名兼容性。

模块命名

  • 仅收集和返回信息的模块**必须**命名为<something>_info。

  • 收集和返回ansible_facts的模块**必须**命名为<something>_facts，并且**不得**返回除事实以外的任何内容。

有关更多信息，请参阅模块开发指南。

集合许可要求

这些指南是包含在 Ansible 软件包中的策略，此外还有可能影响您代码的任何许可和法律问题。

注意

以下指南比严格必要的要求更严格。一旦我们获得 Red Hat 法律部门的批准，我们将尝试添加更广泛的可接受许可证列表。

集合中有多种类型的內容，许可证必须以不同的方式解决这些内容。

  • **必须**使用与GPL-3.0-或更高版本**兼容**的自由软件许可证许可的內容

    • modules/目录內容。

    • module_utils/目录內容：ansible-core 通常使用BSD-2-条款许可证允许第三方模块在这些第三方模块具有与 GPLv3 不兼容的许可证的情况下使用module_utils。在许可您自己的module_utils时，请考虑此用例。

    • plugins/之外的代码：如果它**不**导入在GPL-3.0-or-later下获得许可的代码，则它可以在另一个与GPL-3.0-or-later兼容的许可证下获得许可。

    • 非代码內容。

    • 要获得允许，许可证**必须**被认为是开源的，并且与GPL-3.0-or-later在**两者**上兼容

  • **必须**使用GPL-3.0-或更高版本许可的內容

    • plugins/目录中的所有其他代码，除了modules/和module_utils/目录下的代码（请参见上文）：这些插件在 Ansible 控制器进程内部运行，该进程在GPL-3.0-or-later下获得许可，并且通常必须导入来自控制器的代码。由于这些原因，**必须**使用GPL-3.0-or-later。

    • plugins/之外的代码：如果它导入任何其他在GPL-3.0-or-later下获得许可的代码。请注意，这尤其适用于单元测试，这些测试通常会导入来自 ansible-core、plugins/、module_utils/或modules/的代码，并且此类代码通常在GPL-3.0-or-later下获得许可。

贡献者许可协议

集合**不得**要求社区贡献者签署任何类型的贡献者许可协议 (CLA)，除了开发者原始码证书 (DCO)或仅要求确认贡献来源的类似协议。此要求旨在维护社区对其贡献的所有权，防止因一个实体拥有整个项目的版权而可能发生的意外许可更改，并降低贡献的门槛。

存储库管理

  • 每个集合**必须**具有一个公共 Git 存储库。

  • 集合的版本**必须**在其存储库中进行标记。

    • 必须使用带有tag参数的git工具来标记发布版本。

    • 标签名称必须与Galaxy版本号完全匹配。

    • 标签名称可以有v前缀。

    • 标签名称必须在每次发布版本时保持一致的格式。

  • 发布到Galaxy的集合工件必须使用集合Git仓库中标记为该版本的源代码构建。

    • 构建过程中进行的任何更改必须有明确的文档记录，以便可以重现集合工件。

分支名称和配置

注意

本小节**仅**适用于ansible-collections下的仓库！其他集合仓库也可以遵循这些指南，但不是必须的。

  • 所有新仓库必须将main作为默认分支。

  • 拉取请求设置必须禁止merge commits。

  • 以下分支保护规则必须为所有发布分支启用

    • Require linear history

    • Do not allow bypassing the above settings

CI测试

注意

您可以从collection_template仓库复制免费使用的GitHub action工作流文件到您集合的.github/workflows目录，以通过GitHub actions设置测试。该工作流涵盖了以下所有要求。

及时添加新的ansible-core版本，并考虑停止支持和测试其EOL版本以及您的集合不支持的版本。

如果您的集合仓库位于ansible-collections GitHub组织下，请记住，测试作业的数量是有限的，并且在组织中的所有集合之间共享。因此，请专注于您集合的良好测试覆盖率，避免对不必要的实体进行测试，例如您的集合不支持的ansible-core EOL版本。

为了接收可能影响集合的重要公告（例如，测试），集合维护者应

  • 订阅news-for-maintainers仓库。

  • 加入Collection Maintainers & Contributors论坛组。

  • 您必须从最新的稳定ansible-base/ansible-core分支运行ansible-test sanity命令。

    • 集合必须运行等效于ansible-test sanity --docker命令的命令。

      • 如果它们不使用--docker，则必须确保所有测试都运行，特别是编译和导入测试（应针对所有支持的Python版本运行）。

      • 集合可以选择跳过它们明确不支持的某些Python版本；这需要在README.md和每个模块和插件中进行记录（提示：使用文档片段）。但是，我们强烈建议您参考Ansible Python兼容性部分以了解更多详细信息。

  • 您还应该从ansible/ansible的devel分支运行ansible-test sanity，以便更早地了解新的代码风格检查要求。

  • 健全性测试必须通过。

    • 您应避免向test/sanity/ignore*.txt文件添加条目以使您的测试通过，但允许这样做，除非在下面列出的情况下。

    • 您必须不要忽略以下验证。在批准之前，必须修复并从文件中删除它们

      • validate-modules:doc-choices-do-not-match-spec

      • validate-modules:doc-default-does-not-match-spec

      • validate-modules:doc-missing-type

      • validate-modules:doc-required-mismatch

      • validate-modules:mutually_exclusive-unknown

      • validate-modules:no-log-needed（在参数规范中使用no_log=False来标记误报！）

      • validate-modules:nonexistent-parameter-documented

      • validate-modules:parameter-list-no-elements

      • validate-modules:parameter-type-not-in-doc

    • 以下验证不得忽略，除非在特定情况下

      • validate-modules:undocumented-parameter：这只能在以下两种情况之一中被忽略

        1. 一个危险的模块参数已被弃用或删除，并且代码存在于告知用户他们不应该再使用此特定参数，或者它有意停止工作。

        2. 模块参数仅用于从伴随的动作插件传递数据。

    • 所有ignore-*.txt文件中的条目必须在每个条目的文件中以注释的形式进行说明。例如plugins/modules/docker_container.py use-argspec-type-path # uses colon-separated paths, can't use type=path。

  • 您必须针对集合支持的每个“主要版本”（2.14、2.16、2.17等）的ansible-core运行CI。（通常是stable-xxx分支的HEAD。）

  • 所有CI测试必须针对每个拉取请求运行，并且在合并之前应通过。

  • 至少健全性测试必须针对发布集合的提交运行；如果它们未通过，则集合将不会发布。

    • 如果集合具有集成/单元测试，则它们也应该运行；如果它们未通过，则应分析错误以决定它们是否应阻止发布。

  • 所有CI测试必须定期运行（每晚或至少每周一次），以确保没有定期提交的仓库针对每个测试的ansible-core版本的ansible-test的最新版本进行测试。必须定期检查定期CI运行的结果。

以上所有操作都可以通过使用GitHub Action模板来实现。

要了解如何向您的集合添加测试，请参阅

在集合之间移动模块时

有关完整详细信息，请参阅将内容迁移到不同的集合。

通常，我们不反对在集合之间移动内容或将Ansible中包含的集合中的内容移动到Ansible包之外的集合中，只要不违反语义版本控制。更准确地说，如果目标集合是原始集合的依赖项，则使用重定向替换内容仅是一项次要更改。（有关向Ansible中包含的集合添加新依赖项的更多信息，请参阅集合依赖项。）

对于社区“通配符”集合，我们有略微不同的规则。我们允许在以下条件下将内容从community.general和community.network移动到Ansible之外的其他集合

  1. 新集合已获得适当的许可，并遵循贡献者许可协议政策。

  2. 在宣布弃用模块的计划后四周内，在过去6个月内为该内容做出贡献的贡献者中没有一个提出异议。

  3. 至少有6个月的弃用期，在此期间将显示弃用警告。弃用通知必须提及该内容已移动到Ansible社区包之外的集合中，并且用户需要单独安装该集合。

  4. 如果社区成员或贡献者在这6个月内提出了取消迁移的充分理由，则指导委员会将在讨论这些理由并进行投票，然后再删除内容。

仅当可以确保完全向后兼容时，才会添加重定向。如果未使用它们，则必须使用墓碑，并且墓碑消息需要明确提及新集合以及新集合中的内容不完全向后兼容。

开发约定

您集合中的所有模块

  • 必须满足约定、提示和陷阱中列出的所有要求。

  • 必须满足幂等性的概念：如果模块使用相同的输入集重复运行，它不会对系统进行任何更改。

  • 不得使用特殊的state选项值（如get、list、query或info）来查询信息 - 创建新的_info或_facts模块（有关更多信息，请参阅模块开发指南）。

  • 所有*_info和*_facts模块必须支持check_mode（有关更多信息，请参阅开发约定）。

集合依赖项

**符号：**如果foo.bar依赖于baz.bam，我们说baz.bam是被依赖的集合，而foo.bar是依赖的集合。

  • 集合不得依赖于ansible包中未包含的集合。

  • 集合依赖项必须发布在Galaxy上。

  • 集合依赖项必须具有版本的下限，该下限至少为1.0.0。

    • 这意味着所有集合依赖项都必须指定版本的下限，并且这些下限应该是稳定的版本，而不是0.x.y形式的版本。

    • 在创建新的集合时，如果集合依赖项也处于开发阶段，则需要注意，因为 Galaxy 会检查依赖项是否存在于所需版本中。

      1. 假设foo.bar依赖于foo.baz。

      2. 首先发布foo.baz的 1.0.0 版本。

      3. 然后修改foo.bar的galaxy.yml文件，为foo.baz指定'>=1.0.0'。

      4. 最后发布foo.bar的 1.0.0 版本。

  • Ansible 中包含的集合之间的依赖关系必须有效。如果违反了依赖关系，则必须固定相关的集合，以便所有依赖关系再次有效。这意味着保留先前版本中的版本号，或仅部分递增版本号，以便生成的版本集没有无效的依赖关系。

  • 如果某个集合在较长时间内具有过于严格的依赖关系，并强制另一个依赖于它的集合被保留，则该集合将从下一个主要 Ansible 版本中删除。什么是“较长时间”取决于下一个主要 Ansible 版本发布的时间。如果某个依赖集合阻止其依赖的集合的新主要版本包含在下一个主要 Ansible 版本中，则该依赖集合将从该主要版本中删除，以避免阻止被依赖的集合。

  • 我们强烈建议集合也针对其依赖项的main分支进行测试，以确保尽早检测到与这些依赖项未来版本的兼容性问题，并及时解决这些问题以避免此类问题。依赖于其他集合的集合必须了解，当它们不确保与最新依赖项版本的兼容性时，它们存在被删除的风险。

  • 包含在 Ansible 中的集合**不得**依赖于其他集合，除非它们满足以下情况之一

    1. 它们对 Ansible 中包含的其他集合的一个（或多个）主要版本具有宽松的依赖关系。例如，ansible.netcommon: >=1.0.0，或ansible.netcommon: >=2.0.0, <3.0.0。如果某个集合依赖于此版本范围之外的新主要版本的发布版本，而这些版本将包含在下一个主要 Ansible 版本中，则该依赖集合将从下一个主要 Ansible 版本中删除。此截止日期为功能冻结日期。

    2. 它们已获得指导委员会的明确许可。

示例

  1. community.foo 1.2.0依赖于community.bar >= 1.0.0, < 1.3.0。

    • 现在community.bar创建了新的 1.3.0 版本。当community.foo没有创建具有宽松依赖关系的新版本时，我们必须在下一个 Ansible 版本中包含community.bar 1.2.x，即使 1.3.0 版本可用。

    • 如果community.foo在一段时间内不放松其对community.bar的依赖关系，则community.foo将从下一个主要 Ansible 版本中删除。

    • 不幸的是，community.bar必须保持在1.2.x版本，直到community.foo被删除（在下一个主要版本中），或者放松其要求以便可以包含更新的community.bar 1.3.z版本。

  2. community.foonetwork依赖于ansible.netcommon >= 2.0.0, <3.0.0。

    • 在此主要 Ansible 版本周期中发布了ansible.netcommon 4.0.0版本。

    • community.foonetwork必须在下一个主要 Ansible 版本的功能冻结日期之前发布一个新版本，该版本允许依赖于所有ansible.netcommon 4.x.y版本，否则它将从下一个主要 Ansible 版本中删除。

其他要求

  • 在内容从其他当前包含的集合（如community.general或community.network）中移出后，或者新集合满足所有要求后，请参阅在ansible-build-data 存储库的 README 中添加新集合。

  • 指导委员会可以拒绝集合包含请求或将集合从 Ansible 包中排除，即使该集合满足本文档中列出的要求。有关详细信息，请参阅集合包含请求工作流程。

另请参阅

Ansible 集合创建者路径

Ansible 集合创建者旅程的一致概述