Add support for test and filter plugins, roles and playbooks

[felixfontein]

Fixes #37. I don't think adding module_utils makes much sense, so I didn't add that. Instead I added basic support for playbooks.

Right now test and filter plugins, and roles and playbooks are not found automatically. They need to be added manually (support for that is missing - right now you have to edit the cangelogs/changelog.yaml manually).

[felixfontein]

I'm currently thinking on how to allow adding new plugins/fragments without editing changelogs/changelog.yaml manually. Maybe adding a (or multiple) fragment(s) like:

---
add plugin.filter:
  - name: to_time_unit
    description: Converts a time expression to a given unit
  - name: to_seconds
    description: Converts a time expression to seconds
add object.role:
  - name: nginx
    description: The most awesome nginx installation role ever
add object.playbook:
  - name: wipe_server
    description: Totally wipes a server

[felixfontein]

Once these objects become documentable (like roles with role argspecs), the changelog generator could detect new objects automatically.

I'm wondering (whether/)how to integrate role entrypoints into this. I guess the entrypoint bar for role foo could be mentioned as a "role" foo.bar (since periods are not allowed in role names), or alternative as a "role" foo/bar (slashes are not allowed either).

[briantist]

I'm not sure which method is best but definitely interested in being able to add tests and filters into a changelog.

[felixfontein]

I'm currently tending to treating role entry points the same way as plugin/module options, i.e. they do not get their own "New Role Entrypoint" entries, but you should use regular minor_change fragments to announce them.

[felixfontein]

@geerlingguy @Shrews since you're more used to roles in collections, what are your opinions on this?

[geerlingguy]

It seems like it would be nice to wait for the complete support for role argspecs before introducing support here.

[Shrews]

I'm not exactly sure what you're wanting a comment on (I'm not going to comment on the code since I'm unfamiliar with it), but it seems that adding any features based on what you're anticipating from the role argspec is very premature at this point. If you're wanting my opinion on entrypoint referencing, making them part of the . name is likely to be confusing, IMO.

[felixfontein]

The main question is: are the objects that users should be informed about roles, or role entrypoints?

[Shrews]

The main question is: are the objects that users should be informed about roles, or role entrypoints?

IMO, roles should be the main thing. I suspect many will have only a single main entrypoint anyway.

[felixfontein]

I'm going to merge this so people can actually try out using it.

One problem right now is that the changelog sanity test in ansible-test (2.10 and 2.11/devel) will not like these fragments, since it's using an older version of antsibull-changelog. I'll release a new version of antsibull-changelog once this is merged, and I'll look into getting the version in ansible-test upgraded.

[felixfontein]

PR for updating the version used by ansible-test sanity: ansible/ansible#73428