4 Commits

Include renames

Author	SHA1	Message	Date
volker.raschekandCopilot	28d4ea523d	fix: declare the dependency on the collection community.general ... On Archlinux ansible.builtin.package resolves to the module pacman, which is shipped by community.general and not by ansible-core. Without the collection the role fails with "Could not find a matching action for the pacman package manager", which surfaced in the molecule scenario as soon as only the explicitly declared collections were installed. Co-authored-by: Copilot <copilot@github.com>	2026-09-08 11:18:29 +02:00
volker.raschekandCopilot	a6e8555e13	refactor(molecule): use docker instead of podman ... The scenario now starts its containers with community.docker instead of containers.podman, because docker is the container runtime available on the CI runner. The connection plugin, the login command and the declared collections were adjusted accordingly and the docker SDK for python is installed in the workflow, since the module requires it. Co-authored-by: Copilot <copilot@github.com>	2026-09-08 10:14:20 +02:00
volker.raschekandCopilot	9cadae0ba3	fix(ci): resolve collections for ansible-lint ... The ansible-lint action only installs collections from a requirements file it knows about. Since this project uses requirements.yaml instead of the auto-detected requirements.yml, the collections were never installed and the syntax-check rule failed with unresolvable modules. The requirements file is now passed explicitly to the action. Additionally containers.podman is declared as dependency, because the molecule scenario uses containers.podman.podman_container. Co-authored-by: Copilot <copilot@github.com>	2026-09-08 09:11:56 +02:00
volker.raschekandCopilot	6d465e5dad	docs: declare the dependency on the collection community.crypto ... The role uses openssl_privatekey, openssl_csr, x509_certificate and x509_certificate_info, but neither declared that collection anywhere nor mentioned it in the readme. A standalone role cannot express collection dependencies in its metadata, so a requirements file next to the readme section is the usual way. The section also documents two requirements that arose from the recent changes and were undocumented as well. Facts have to be gathered, because the package names, the trust store anchor and the update command are resolved by distribution, os_family and architecture. And the role needs become, since it writes into /etc and updates the trust store. No version is pinned. All used modules exist since community.crypto 1.0.0, so a lower bound would be arbitrary. Co-authored-by: Copilot <copilot@github.com>	2026-09-07 22:30:59 +02:00