Skip to content
This repository has been archived by the owner on May 28, 2024. It is now read-only.

Clarify SCM and release requirements #218

Merged
merged 2 commits into from
Oct 26, 2022
Merged

Clarify SCM and release requirements #218

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
410559d
Require git repos
mariolenz Oct 13, 2022
051db8e
Clarify tagging and releasing
mariolenz Oct 15, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion collection_checklist.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ Note for reviewers: If you don't know how to check any of the points below, plea
- [ ] 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)](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html)
- [ ] have a publicly available issue tracker that does not require a paid level of service to create an account or view issues
- [ ] 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

**Standards and documentation:**
- [ ] adheres to [semantic versioning](https://semver.org/)
Expand Down
6 changes: 5 additions & 1 deletion collection_requirements.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -280,7 +280,11 @@ licensing and legal concerns that may otherwise affect your code.
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I'm not opposed to this sentence, it seems unlikely we'll ever make the tooling support other SCM software unless a collection that uses it exists, and if we're preventing it from being added based on that, I doubt we'd ever support them.

I'd also like to know what tooling specifically.. though it doesn't have to be listed in this doc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd also like to know what tooling specifically.. though it doesn't have to be listed in this doc.

Probably collection_prep. I'm not an expert on this tool, but I think it won't work with non-git repositories.

@felixfontein Did you have anything else in mind when saying that we can potentially add more SCMs to the list once our tooling supports them?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd also like to know what tooling specifically.. though it doesn't have to be listed in this doc.

See ansible-community/community-topics#148 (comment). My idea was that we'd set up an automated check to ensure that new collection Galaxy releases are tagged in the respective collection's repository. @felixfontein pointed out that would fall flat if we didn't actually mandate that collections use a git repository.

it seems unlikely we'll ever make the tooling support other SCM software unless a collection that uses it exists, and if we're preventing it from being added based on that, I doubt we'd ever support them.

I guess if a new collection wanted to use some other SCM, that's when we'd consider allowing it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably collection_prep. I'm not an expert on this tool, but I think it won't work with non-git repositories.

I've never used that in any collections I'm working on :)

I was mainly referring to antsibull, and potential future CI / tooling in the ansible-build-data repository. Right now there's nothing in there which depends on collections using git repos, but when we want to start looking at the tags for the releases (and from the discussions, this could very likely be the case), we need to limit the SCMs to something we actively want to (and can) support.

About extending the list of allowed SCMs: we probably only will do it when we have a collection that wants to be included that doesn't use git. I'm not sure whether this will happen anytime soon, but if it does happen, it probably depends a lot on the SCM how it will continue.


Branch name and configuration
-----------------------------
Expand Down