ansible-collections / collection_template Goto Github PK

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

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

Update community.general and community.network to do similar

SUMMARY

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

ISSUE TYPE

• Bug Report

COMPONENT NAME

sanity

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

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

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

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.

@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.

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