[Associated vote ended on 2022-10-26] Collections that don't tag releases

[gotmax23]

Summary

In light of the recent discussions about incongruities between galaxy versions and git tags, I programmatically went through all of the collections in the Ansible package, extracted their repository URL from the Galaxy API, and then got a list of their tags from Github.

The first thing I noticed is there are multiple collections that don't tag their releases at all. The following repositories do not have any git tags. Some of them seem to have release commits (e.g. https://github.com/F5Networks/f5-ansible/commit/3ab145bdee137648be434c7688e22210f2b99b56), but I don't think that's sufficient.

• [x] https://github.com/F5Networks/f5-ansible (f5networks.f5_modules) -- https://github.com/F5Networks/f5-ansible/issues/2266
• [x] https://github.com/CiscoDevNet/ansible-nso (cisco.nso) -- Has been removed from Ansible 9
• [x] https://github.com/cyberark/ansible-security-automation-collection (cyberark.pas) -- https://github.com/cyberark/ansible-security-automation-collection/issues/46
• [x] https://github.com/ansible-collections/mellanox.onyx (mellanox.onyx). This is already slated for removal, so we won't be reporting an issue against it.
• [x] https://github.com/wtinetworkgear/wti-collection (wti.remote) -- https://github.com/wtinetworkgear/wti-collection/issues/10

The fortinet collections mark releases by creating a separate branch for each release. Even under the current rules, I don't think this counts as tagging.

• [x] https://github.com/fortinet-ansible-dev/ansible-galaxy-fortimanager-collection (fortinet.fortimanager) -- https://github.com/fortinet-ansible-dev/ansible-galaxy-fortimanager-collection/issues/53
• [x] https://github.com/fortinet-ansible-dev/ansible-galaxy-fortios-collection (fortinet.fortios) -- https://github.com/fortinet-ansible-dev/ansible-galaxy-fortios-collection/issues/207

[gotmax23]

Currently, the guidelines say the following about tagging:

Every collection MUST have a public SCM repository and releases of the collection MUST be tagged in this repository.

I think this should be made stricter and more explicit. I will propose better wording later when I'm less tired :). I'll also put the data somewhere where others can look at it.

[mariolenz]

I think that https://github.com/CiscoDevNet/ansible-nso (cisco.nso) might be unmaintained: The last commits, releases or CI runs are more than 1 year old. So maybe we should deprecate this collection.

I've already found this one in ansible-community/community-topics#128 but I think I haven't done anything about this yet.

[gotmax23]

Here is my proposed update:

Every collection MUST have a public SCM repository, and releases of the collection MUST be tagged in this repository. For git repositories, this means that releases MUST be git taged and that the tag name MUST exactly match the Galaxy version number. Tag names MAY have a v prefix, but tag names MUST remain consistent.

Additionally, collection artifacts published to Galaxy MUST be built from the sources that are tagged in the repository as that release. Any changes made during the build process MUST be clearly documented so the collection artifact can be reproduced.

[gotmax23]

Here is the data: https://paste.sr.ht/~gotmax23/0d00df200b6a7e9809bdb402544f3098260444f1 https://paste.sr.ht/~gotmax23/82077a3677559137bd21f51e633864f05438a8bb

It includes the repository URLs and the last 5 all of the tags in the collection's repo. The version numbers are from ansible-7.0.0a1.deps.

[gotmax23]

We discussed this in today's Community meeting. I'll create a guidelines PR and start a vote in a few days if there's no major objections to the new wording. After that, I'll create issues against each collection that violates this rule.

@mariolenz proposed amending the collection removal policy to explicitly state that collections with unresolved guidelines violations are considered unmaintained.

@Andersson007 suggested that the guidelines should recommend collections not under the community namespace to also the Zuul release pipeline to hopefully prevent issues like this.

Eventually, I'd like to add collections' repository URLs and version tag formats to ansible-build-data and have an automated check to make sure the releases are tagged. We could also have antsibull-build put a file in the ansible package with links to the full source of each collection. That's probably a separate discussion, but I'm jotting it down here so I don't forget. This was very briefly discussed in the meeting.

[felixfontein]

We discussed this in today's Community Steering Committee meeting

Is that a new name for the community meeting? :)

I'm +1 to @mariolenz's suggestion.

I'm also +1 to more closely linking collections and collection source repositories. For that, we probably have to restrict the allowed SCMs though. I guess we should first stricten the guidelines to require git repositories (maybe more SCM types later, but git suffices right now because that's what everyone is using), and then start implementing something.

[gotmax23]

We discussed this in today's Community Steering Committee meeting

Is that a new name for the community meeting? :)

/me is in too many meetings :).

I'm also +1 to more closely linking collections and collection source repositories. For that, we probably have to restrict the allowed SCMs though. I guess we should first stricten the guidelines to require git repositories (maybe more SCM types later, but git suffices right now because that's what everyone is using), and then start implementing something.

Currently, every collection uses Github except openstack.cloud which uses the opendev.org Gitea instance. Both Github and Gitea (used by opendev.org), have API endpoints to get a list of tags. I don't think it's likely that new collections will use mercurial or svn or something. I think we can cross that bridge if/when we come to it.

Implementing support for Github, Gitea, and Gitlab is a good start. We could implement a fallback that actually clones a git repository and extracts the tags, but that should be a last resort, as it would be quite slow. I'm also not sure we need to implement the fallback until a new collection actually starts using another git forge.

My main question is whether this check should be integrated in antsibull or somewhere else and how the data file should be formatted/stored in ansible-build-data.

[felixfontein]

I don't see why we would need special support for GitHub, GitLab, or Gitea. Why not simply support git?

git ls-remote --help
git ls-remote --tags https://opendev.org/openstack/ansible-collections-openstack.git
git ls-remote --tags https://github.com/ansible-collections/community.rabbitmq.git 

[mariolenz]

I don't see why we would need special support for GitHub, GitLab, or Gitea. Why not simply support git?

On the one hand, I agree since those are just different "git services".

On the other hand, we require that all collections MUST have a public SCM repository. Actually, most people will use git nowadays but in theory, they could use any obscure SCM as long as the repo is publicly available.

This question might be a bit out of scope for this issue, but should we require a public git repository? Instead of a (generic) SCM repository?

[felixfontein]

@mariolenz I'm for requiring that one, and mentioning that we can potentially add more SCMs to the list once our tooling supports them. Not that anything gets the impression that we're making random requirements here :)

[gotmax23]

I don't see why we would need special support for GitHub, GitLab, or Gitea. Why not simply support git?

git ls-remote --help
git ls-remote --tags https://opendev.org/openstack/ansible-collections-openstack.git
git ls-remote --tags https://github.com/ansible-collections/community.rabbitmq.git 

I did not know about git ls-remote. I agree that is likely a better solution.

[gotmax23]

@mariolenz I'm for requiring that one, and mentioning that we can potentially add more SCMs to the list once our tooling supports them. Not that anything gets the impression that we're making random requirements here :)

For folks who aren't subscribed to both repositories, @mariolenz created https://github.com/ansible-collections/overview/pull/218 to require this.

[mariolenz]

Updated suggestion to avoid having two discussions / PRs / votes:

collection_checklist.md:

- - [ ] have a public SCM repository, releases of the collection are tagged in this repository
+ - [ ] have a public git repository, releases of the collection are tagged in this repository

collection_requirements.rst:

Repository management
=====================

- Every collection MUST have a public SCM repository and releases of the collection MUST be tagged in this repository.
+ Every collection MUST have a public git repository. Releases of the collection MUST be tagged in said repository. This means that releases MUST be ``git tag``ed and that the tag name MUST exactly match the Galaxy version number. Tag names MAY have a ``v`` prefix, but a collection's tag names MUST have a consistent format from release to release.
+ 
+ Additionally, collection artifacts released to Galaxy MUST be built from the sources that are tagged in the collection's git repository as that release. Any changes made during the build process MUST be clearly documented so the collection artifact can be reproduced.
+ 
+ We are open to allowing other SCM software once our tooling supports them.

[felixfontein]

+1 to the new proposal.

[mariolenz]

I'll create a guidelines PR and start a vote in a few days if there's no major objections to the new wording.

@gotmax23 I've re-opened ansible-collections/overview#218 and merged your suggestion. If there are more things you want to change, you could add them there. Or, if you prefer, I could close it again and you open a new one.

If it's OK for you now and you don't want to change anything else, I think we should open a vote on this.

[gotmax23]

xref to the vote: https://github.com/ansible-community/community-topics/discussions/153

[mariolenz]

I counted votes: 8 x +1 from SC (mariolenz gotmax23 briantist felixfontein Andersson007 markuman russoz acozine), no vote from community this time.

Can someone from the Steering Committee please confirm?

[Andersson007]

I counted votes: 8 x +1 from SC (mariolenz gotmax23 briantist felixfontein Andersson007 markuman russoz acozine), no vote from community this time.

Can someone from the Steering Committee please confirm?

I've checked and confirm the result: 8 SC x +1, no one is against

[mariolenz]

In that case the proposal has been accepted. Can someone please approve / merge ansible-collections/overview#218?

Thanks all!

[Andersson007]

closed via https://github.com/ansible-collections/overview/pull/218 , thanks everyone!

[gotmax23]

I've reopened this to track filing issues against the seven offending collections. If someone really wants that to be a separate issue, let me know, and I'll create one.

[gotmax23]

I plan on announcing this on the Bullhorn and maybe in https://github.com/ansible-collections/news-for-maintainers/. For the collections that violate this, what should the maintainers be asked to do? I was thinking of asking them to retroactively tag the last release or two. What do you think?

[mariolenz]

I plan on announcing this on the Bullhorn and maybe in https://github.com/ansible-collections/news-for-maintainers/.

The Bullhorn sounds like a good place to announce this an remember collection maintainers to tag their releases. I'm not sure about https://github.com/ansible-collections/news-for-maintainers/ though. Maybe @Andersson007 or @felixfontein could say if this is a good idea.

Besides, just to make sure you might want to open issues in the problematic repos that they should tag their releases. Although not in mellanon.onyx since it looks unmaintained and will be removed in Ansible 8(?), anyway.

For the collections that violate this, what should the maintainers be asked to do? I was thinking of asking them to retroactively tag the last release or two. What do you think?

I think the minimum would be to tag the latest / current release. Of course, it would be nice if people would tag all past releases but the important thing is they tag all future ones.

[felixfontein]

I would ask them to at least tag the last 1-2 releases, though I personally would prefer if they tag all. Probably also depends on how many they had, if they only had very few it shouldn't be much work anyway.

About news-for-maintainers: I would only announce there a general reminder to do this, but I don't think it's necessary if we inform the collections who violate this directly.

[gotmax23]

@mariolenz:

Besides, just to make sure you might want to open issues in the problematic repos that they should tag their releases. Although not in mellanon.onyx since it looks unmaintained and will be removed in Ansible 8(?), anyway.

Yes, the plan was to copy and paste the same issue for each repository. I'll skip mellanox.onyx, but I don't think it would hurt to file an issue for that one; we'd just have more evidence that it's unmaintained.

@felixfontein:

I would ask them to at least tag the last 1-2 releases, though I personally would prefer if they tag all.

Me too. I'll ask maintainers to tag at least the last two releases.

About news-for-maintainers: I would only announce there a general reminder to do this, but I don't think it's necessary if we inform the collections who violate this directly.

Yeah, I wanted to post a general reminder in addition to the other issues. I noticed one collection which tagged releases inconsistently that's not in the seven above, and I didn't check for collections that may violate the guideline we added about reproducibility[^1]. I think a general reminder would be useful.

[^1]: "Additionally, collection artifacts released to Galaxy MUST be built from the sources that are tagged in the collection's git repository as that release. Any changes made during the build process MUST be clearly documented so the collection artifact can be reproduced."

[gotmax23]

How's this?

---

Hi! The Ansible Community Steering Committee has determined that this collection does not tag its releases in its git repository. This violates the repository management section of the Collection Requirements:

Every collection MUST have a public git repository. Releases of the collection MUST be tagged in said repository. This means that releases MUST be git taged and that the tag name MUST exactly match the Galaxy version number. Tag names MAY have a v prefix, but a collection's tag names MUST have a consistent format from release to release.

Additionally, collection artifacts released to Galaxy MUST be built from the sources that are tagged in the collection's git repository as that release. Any changes made during the build process MUST be clearly documented so the collection artifact can be reproduced.

Note that this requirement has recently been clarified, but its intent remains the same. Please tag at least the previous 1-2 releases of your collection to come into compliance.

Please keep us updated and let us know if you have any questions. Thanks!

---

[mariolenz]

Note that this requirement have recently been clarified, but the substance has not changed too much.

Personally, I'd remove the "too much". Apart from this your suggestion looks good to me.

[russoz]

Wordsmithing a bit:

"... clarified, but its intent remained the same."

BTW, @mariolenz , @gotmax23 , @felixfontein thanks for chasing these issues.

[gotmax23]

I've reported issues against the offending collections. Please the edits I've made to the issue description. I skipped the two collections that are already slated for removal.

[mariolenz]

I skipped the two collections that are already slated for removal.

I've reported an issue against cisco.nso because we didn't decide yet to remove it. I've just started the process.

[felixfontein]

@mariolenz good point. I guess what happens with the issue there also helps us deciding whether it is still maintained :)

[gotmax23]

I've submitted https://github.com/ansible-community/ansible-build-data/pull/176 to add a data file with collection's repository URLs. I also submitted https://github.com/ansible-community/antsibull/pull/456 to add a validate-tags subcommand to antsibull-build that ensures collections' releases are tagged. Feedback welcome!

[gotmax23]

I also opened issues against hpe.nimble and inspur.sm which tagged their other releases but not the most recent ones:

• https://github.com/hpe-storage/nimble-ansible-modules/issues/59
• https://github.com/ISIB-Group/inspur.sm/issues/57

[gotmax23]

We've followed up with cyberark.pas (no response and no action) and fortinet.fortimanager (response but no action). We plan to start the removal process for cyberark.pas if there's no response by next week.

[mariolenz]

@Andersson007 @felixfontein @russoz I think we should close this issue. Feel free to re-open it again if you think I'm wrong!

[gotmax23]

Yes, let's close this. Ansible 10 has no more failures, and we are dealing with new ones as they come up.