New collection review: community.sops

[endorama]

Hello, I'd like to submit community.sops collection for review to have it included in Ansible 3.0.0.

Following along ansible/community#546 (comment), here the requested information:

Collection on Galaxy (version 1.0.2)
Collection Source code: https://github.com/ansible-collections/community.sops
Collection issue tracker: https://github.com/ansible-collections/community.sops/issues
Collection maintainer: @endorama

We tracked in this milestone all work to be compliant with requirements.

Thank you for your help and your time.

[tadeboro]

Hi @endorama!

The community has agreed on a list of criteria that must be met to move forward with the inclusion of a collection in the Ansible package. For this discussion, we will use a shortened checklist to verify and record compliance, but you can find the full details in the Collection Requirements documentation.

This is a new and gradual process, and we will edit this comment as we progress along. The items in the checklist can be in one of the following states:

• Items with a checkmark and no attached comment are OK and need no intervention from your side.
• Items with a checkmark that contain a comment will not block the inclusion process, but by following the advice given in the comment, the collection's quality can be improved.
• Items with no checkmark and no extra details are waiting for evaluation.
• Items with no checkmark that contain at least one comment need your attention. Issues in comments marked as required need to be fixed before collection can be included in Ansible. Comments marked as optional are just friendly advice and will not block the inclusion.

Feel free to ask any questions and provide feedback. Thanks in advance for your understanding.

Public availability and communication:

• published on Ansible Galaxy Ansible Galaxy with version 1.0.0 or later
• has a policy of releasing, versioning and deprecation announced to contributors and users in some way
• have a Code of Conduct (CoC) compatible with the Ansible Code of Conduct (CoC)
• have a publicly available issue tracker that does not require a paid level of service to create an account or view issues

Standards and documentation:

• adheres to semantic versioning
• follows licensing rules
• follows the Ansible documentation standards and the style guide
• follows development conventions
• has README.md
• documentation, examples, and return use FQCNs for M(..), examples, and seealso subsections
• modules (or plugins) from ansible-base use ansible.builtin. as a FQCN prefix
• documentation and return sections use version_added: containing the collection version for which an option, module, or plugin was added
• FQCNs is used for extends_documentation_fragment:, unless you are referring to doc_fragments from ansible-base

Collection management:

• galaxy.yml having tags field set
• collection dependencies must have a lower bound on the version which is at least 1.0.0 and are all part of the ansible package
• meta/runtime.yml defines the minimal version of Ansible which the collection works with
• has changelog, preferably with changelogs/changelog.yaml

Tests:

• passed ansible-test sanity
• if test/sanity/ignore*.txt exists, it does not contain error codes listed here
• has CI tests up and running against each of the "major versions" of ansible-base/ansible-core that the collection supports
• all CI tests run against every pull request
• all CI tests run against a commit that releases the collection; if they don't pass, the collection won't be released
• all CI tests run regularly (nightly, or at least once per week)

[tadeboro]

I finished my initial review and found only two blockers for inclusion which should not take much time to resolve.

I did notice that the README file content is a bit outdated in some places (the support matrix is missing at least the latest release, included content section is missing modules). But these minor issues do not block the inclusion process, I just thought that I would point them out since I noticed them during the review process.

All in all, great work, @endorama!

[felixfontein]

Nightly CI runs are added by ansible-collections/community.sops#49

[felixfontein]

README improvements, including a section on releasing, versioning and deprecation, in ansible-collections/community.sops#50

[endorama]

Hi @tadeboro, thank you for the review.

@felixfontein thanks as usual for your fast contributions!

I merged both PR, let me know if anything else need work!

[tadeboro]

I checked again two unfulfilled requirements and I am happy to conclude this review with approval. Great work @endorama and @felixfontein!

[Andersson007]

@felixfontein i fixed minor doc and flake8 issues ansible-collections/community.sops#52

[Andersson007]

Public availability and communication:

• published on Ansible Galaxy Ansible Galaxy with version 1.0.0 or later
• has a policy of releasing, versioning and deprecation announced to contributors and users in some way
• have a Code of Conduct (CoC) compatible with the Ansible Code of Conduct (CoC)
• have a publicly available issue tracker that does not require a paid level of service to create an account or view issues

Standards and documentation:

• adheres to semantic versioning
• follows licensing rules
• follows the Ansible documentation standards and the style guide
• follows development conventions
• has README.md
• documentation, examples, and return use FQCNs for M(..), examples, and seealso subsections
• modules (or plugins) from ansible-base use ansible.builtin. as a FQCN prefix
• documentation and return sections use version_added: containing the collection version for which an option, module or plugin was added
• FQCNs is used for extends_documentation_fragment:, unless you are referring to doc_fragments from ansible-base

Collection management:

• galaxy.yml having tags field set
• collection dependencies must have a lower bound on the version which is at least 1.0.0, and are all part of the ansible package
• meta/runtime.yml defines the minimal version of Ansible which the collection works with
• has changelog, preferably with changelogs/changelog.yaml

Tests:

• passed ansible-test sanity
• if test/sanity/ignore*.txt exists, it does not contain error codes listed here
• has CI tests up and running against each of the "major versions" of ansible-base/ansible-core that the collection supports
• all CI tests run against every pull request
• all CI tests run against a commit that releases the collection; if they don't pass, the collection won't be released
• all CI tests run regularly (nightly, or at least once per week)

[felixfontein]

@tadeboro created a PR for inclusion in Ansible 3.0.0: ansible-community/ansible-build-data#52

[dmsimard]

Pull request has been merged, thank you @tadeboro and @Andersson007 for reviewing !