Ansible Inclusion

[displague]

This issue is tracking remaining Ansible Collections requirements checklist (https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst) items:

• [ ] #24 has a policy of releasing, versioning and deprecation announced to contributors and users in some way @Andersson007: cannot find, MUST be fixed (via an issue for example, see examples in collections, such issues are usually pinned)
• [ ] #25 adheres to semantic versioning @Andersson007: I can't see semver mentioned neither in README no in anywhere else. MUST be fixed.
• [ ] #26 follows the Ansible documentation standards and the style guide @Andersson007: The following issues found (I understand that the stuff was moved from c.g. but we fix these things when find them and we claim it for all new content):

  return device_id: no sample (check everywhere)
  short_description: line 1 ends with a dot (must not)
  return capacity: line 1 does not end with a dot (in return sections lines must end with a dot)
  no "notes" section, it should, at least, contain info about check_mode support, please put something like:
  notes:
  - Supports / Does not support C(check_mode).
  opt user_data: line 1 does not end with a dot (pleas recheck all the options end with a dot).

• [ ] #27 modules (or plugins) from ansible-base use ansible.builtin. as a FQCN prefix @Andersson007: plugins/modules/device.py: - {{ lookup('file', 'my_equinix_metal_sshkey') }} MUST be ansible.builtin.file
• [ ] 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)

Originally from https://github.com/ansible-collections/ansible-inclusion/discussions/15

[displague]

I believe the CI testing requirements are already in place via:

• https://github.com/equinix/ansible-collection-metal/tree/main/.github/workflows
• https://github.com/equinix/ansible-collection-metal/actions

Perhaps https://github.com/equinix/ansible-collection-metal/issues/21 is a blocker.

[vielmetti]

According to https://github.com/ansible-community/community-topics/issues/10 there were some blockers for consideration for Ansible 4.

[vielmetti]

https://meetbot.fedoraproject.org/ansible-community/2021-04-28/ansible_community_meeting.2021-04-28-18.00.log.html#l-343 is the discussion; the recommendation is to target Ansible 5, about 6 months out.

[felixfontein]

• [ ] CI currently does not run against the stable-2.11 branch of ansible-core, which is the basis of Ansible 4 (earlier comment on that).

[vielmetti]

Noted at https://github.com/equinix/ansible-collection-metal/issues/34

[vielmetti]

Also noted https://docs.ansible.com/ansible-core/devel/roadmap/ROADMAP_2_12.html the roadmap for stable-2.12 which is the basis for Ansible 5:

2021-08-30 Feature Freeze No new functionality (including modules/plugins) to any code
2021-09-13 Beta 1
2021-09-20 Beta 2 (if necessary)
2021-10-04 Release Candidate 1 (and stable-2.12 branching from devel)
2021-10-11 Release Candidate 2 (if necessary)
2021-10-25 Release

which suggests that future Ansible 5 work will have a short 3-week window in October to finish up and adjust the CI to be sure that we have the right tests in place.