ansible-collections / collection_template

A GitHub Template repo to use as the basis for future repos

collection_template

You can build a new repository for an Ansible Collection using this template by following Creating a repository from a template. This README.md contains recommended headings for your collection README.md, with comments describing what each section should contain. Once you have created your collection repository, delete this paragraph and the title above it from your README.md.

Foo Collection for Ansible

Our mission

At the your collection name, our mission is to produce and maintain simple, flexible, and powerful open-source software tailored to your collection purpose.

We welcome members from all skill levels to participate actively in our open, inclusive, and vibrant community. Whether you are an expert or just beginning your journey with Ansible and your collection name, you are encouraged to contribute, share insights, and collaborate with fellow enthusiasts!

Code of Conduct

We follow the Ansible Code of Conduct in all our interactions within this project.

If you encounter abusive behavior, please refer to the policy violations section of the Code for information on how to raise a complaint.

Communication

• Join the Ansible forum:

  • Get Help: get help or help others.
  • Posts tagged with 'your tag': subscribe to participate in collection-related conversations.
  • Refer to your forum group here if exists: by joining the team you will automatically get subscribed to the posts tagged with your group forum tag here.
  • Social Spaces: gather and interact with fellow enthusiasts.
  • News & Announcements: track project-wide announcements including social events.

• The Ansible Bullhorn newsletter: used to announce releases and important changes.

For more information about communication, see the Ansible communication guide.

Contributing to this collection

The content of this collection is made by people like you, a community of individuals collaborating on making the world better through developing automation software.

We are actively accepting new contributors and all types of contributions are very welcome.

Don't know how to start? Refer to the Ansible community guide!

Want to submit code changes? Take a look at the Quick-start development guide.

We also use the following guidelines:

• Collection review checklist
• Ansible development guide
• Ansible collection development guide

Collection maintenance

The current maintainers are listed in the MAINTAINERS file. If you have questions or need help, feel free to mention them in the proposals.

To learn how to maintain/become a maintainer of this collection, refer to the Maintainer guidelines.

It is necessary for maintainers of this collection to be subscribed to:

• The collection itself (the Watch button -> All Activity in the upper right corner of the repository's homepage).
• The news-for-maintainers repository.

They also should be subscribed to Ansible's The Bullhorn newsletter.

Governance

The process of decision making in this collection is based on discussing and finding consensus among participants.

Every voice is important. If you have something on your mind, create an issue or dedicated discussion and let's discuss it!

Tested with Ansible

External requirements

Supported connections

Included content

Using this collection

Installing the Collection from Ansible Galaxy

Before using this collection, you need to install it with the Ansible Galaxy command-line tool:

ansible-galaxy collection install NAMESPACE.COLLECTION_NAME

You can also include it in a requirements.yml file and install it with ansible-galaxy collection install -r requirements.yml, using the format:

---
collections:
  - name: NAMESPACE.COLLECTION_NAME

Note that if you install the collection from Ansible Galaxy, it will not be upgraded automatically when you upgrade the ansible package. To upgrade the collection to the latest available version, run the following command:

ansible-galaxy collection install NAMESPACE.COLLECTION_NAME --upgrade

You can also install a specific version of the collection, for example, if you need to downgrade when something is broken in the latest version (please report an issue in this repository). Use the following syntax to install version 0.1.0:

ansible-galaxy collection install NAMESPACE.COLLECTION_NAME:==0.1.0

See using Ansible collections for more details.

Release notes

See the changelog.

Roadmap

More information

• Ansible user guide
• Ansible developer guide
• Ansible collections requirements
• Ansible community Code of Conduct
• The Bullhorn (the Ansible contributor newsletter)
• Important announcements for maintainers

Licensing

GNU General Public License v3.0 or later.

See LICENSE to see the full text.

collection_template's Issues

Sanity tests should use coverage by default like the other tests

SUMMARY

@mattclay mentioned that coverage should be used on sanity tests here: ansible/ansible#75647 (comment)

ISSUE TYPE

• Bug Report

COMPONENT NAME

sanity

changelog lint example

SUMMARY

I think this repo should provide a snippet example how collections can/should lint their changelogs (if they use antsibull at least).

This started as a discussion in #ansible-community with @gundalow and @felixfontein, and I thought writing down my ideas here would be good.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

examples

ADDITIONAL INFORMATION

I think the following two checks should be executed:

1. ensure a PR needs and has a changelog snippet
2. ensure the snippet has valid syntax (antsibull-changelog lint)

Number 2 is rather easy, we have a tool for that. Number 1 is not.

I think we should only enforce changelog entries for parts of the repository (ain't nobody needs a changelog entry when we fix something in .github/), so I think the example should only care about plugins/ (the users then can easily extend that to their needs).

On IRC it was mentioned that new plugins don't need a fragment -- correct, but at the same time nothing validates the version_added entry right now (will that change?) and (as also mentioned on IRC) filter plugins don't have that anyways.

So the simple (lol) logic that we could go for today would be something like:

if (file changed in plugins/ OR file deleted in plugins/ OR file added in plugins/filters/):
    ensure file added in changelogs/fragments/

This won't catch everything, but it's IMHO a good enough 80% solution we should start wirh.

From experience in other projects, there should be a way to ignore this check. Either by adding a "trivial" label or by adding "no issue" somewhere in the commit/PR message. So that will make the above logic a bit more convoluted (at least when implementing it), but at the same time it's not strictly MVP.

Disable GHA runs for this repo

@gundalow GitHub Actions workflow run in the template repo and create an impression that it's broken. It doesn't really make sense to run them here. Let's try disabling them so that red CI wouldn't contribute to the confusion.

devel branch now requires python >= 3.9

SUMMARY

See title

ISSUE TYPE

• Bug Report

COMPONENT NAME

ANSIBLE VERSION

COLLECTION VERSION

CONFIGURATION

OS / ENVIRONMENT

STEPS TO REPRODUCE

Clone/fork this repository and run the included github workflows.

EXPECTED RESULTS

Green checkmarks

ACTUAL RESULTS

An error similar to this one:

https://github.com/mgit-at/ansible-collection-roles/runs/7622603379

Apparently the ubuntu-latest runner in gh-workflows isn't THAT "latest", as Ubuntu 22.04 runs Python 3.10. The runner I got ran 20.04 instead. Probably needs to be ubuntu-22.04 instead: https://github.com/actions/virtual-environments

[1w] Example GitHub Action Workflow

SUMMARY

Add functional GitHub Action workflow file

• Sanity
• Units
• Integration Test
  • With manually installed Collection dependencies
• Add lots of comments
• Variety of Python Versions

Reviews:

• MattC
• webknjaz

GitHub Action: test-requirements.yml

Remove GitHub Action vendor lock in by using test-requirements.yml
#5 (review)

Update community.general and community.network to do similar

Update GitHub Actions versions in workflows

Many GitHub Actions from GitHub and even third parties have had major version bumps recently, looking to replace Node 12 (EoL this month) with a newer version.

This includes checkout, setup-python, and codecov which have all bumped to v3, github-script is up to v6, for anyone else using them, the peter-evans/find-comment and peter-evans/create-or-update-comment are up to v2.

We should go through and update. Opening an issue in case I can't get to a PR today.

Should we announce in news for maintainers?

Also consider dependabot for this in the future (separate discussion): https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

Example PRs:

• ansible-community/github-docs-build#32
• ansible-collections/community.hashi_vault#243
• lowlydba/lowlydba.sqlserver#59

Add antsibull-changelog to collection_template

In ansible-collections/overview#90 (comment) we are suggesting that people use antsibull-changelog, so lets include the basic framework for this.

Liberal License

SUMMARY

Since this repo is a template, I think we should license it liberally such as MIT or BSD. otherwise, Apache 2 licensed collections can't use this as their template due to licensing.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

ADDITIONAL INFORMATION