Enforce collection tagging policy as a release blocker

[gotmax23]

Summary

Last year in #148, we agreed that all collections must tag their releases in their git repository and clarified the Repository management section of the Collection Requirements.

I also enabled support in antsibull to ensure that collections follow the policy with the antsibull-build validate-tags subcommand (ansible-community/antsibull-build@b38fd8b), include a yaml tag data file in ansible-build-data and the ansible sdist (ansible-community/antsibull-build@5d39db6), and finally added support to the validate-tags subcommand to ignore specific collections when reporting errors (ansible-community/antsibull-build@015f935).

Now that we have the last change which allows us to ignore certain collections such as cisco.nso that have been removed for not fixing this issue, I'd like to make improperly tagged collections a release blocker. Noncompliant collections would fail the release playbook, we'd have to pin them to the last release, and we'd have to file issues against the collections' respective repositories. What do other SC members and the release engineers (/cc @ansible-community/release-managers @rooftopcellist) think? I would document the new process in the ansible-build-data repository¹, add a list of collections to ignore, and update the release playbook to fail on tag validation errors for new ansible versions.

Footnotes

1. or wherever else this should be documented. In general, I'd like to clarify the documentation about the release process, especially with https://github.com/ansible-community/community-team/issues/160 being considered, but I disgress... ↩

[gotmax23]

I've tagged this for the next meeting

[rooftopcellist]

++, that makes sense to me. However, I would like to always maintain a "releasible" state if possible. So I think it would be better if we had a nightly job that would fail ahead of time so that we can raise the flag, pin and open an issue in the collection's repo ahead of release day.

[anweshadas]

+1 from me for the idea. But it would be good if we have some practical examples of pinning, flagging and opening issue in the collection repo. A good and up to date documentation hopefully will solve the majority of the problem in here. Also we have to make sure the collection maintainers understands this step properly.

[acozine]

Agreed that we should have documentation of the entire release process. However, that may take some time to create.

As a temporary stop-gap, we could add documentation about the tagging policy discussed here to the docs at: https://docs.ansible.com/ansible/latest/community/collection_contributors/collection_requirements.html#collections-requirements.

[acozine]

Related? https://github.com/ansible-community/nightly-builds

[mariolenz]

I think we're already doing this (see ansible-community/ansible-build-data#365 for an example).

If there's more to discuss, please open a topic in the forum.