Skip to content

community.molecule

Ansible Molecule collection contains molecule specific plugins.

Health score

85 / 100

Excellent

Strong evidence across everything we could observe.

How bands are set →

  1. Excellent (this collection)
  2. Good
  3. Fair
  4. Poor
  5. Not scored

Observed 6 of 8 signal groups.

Four are needed before a score is published.

4 needed

Category subscores

Security
100%
Trust
85%
Quality
63%
Maintenance
93%
ansible-core compatibility
100%
Every signal we evaluated for this collection
Signals we could observe
security.dependency_boundednessPassedno dependencies declared1 / 1Published artifact
trust.link_claimsPartly met3 of 4 link URLs declared0.85 / 1Published artifact
quality.docsPartly metreadme, 0 doc files1.5 / 3Published artifact
quality.changelogPassedchangelog.yaml, 1 fragment2 / 2Published artifact
quality.license_qualityPassedSPDX id declared (MIT)1 / 1Published artifact
quality.testsPartly metplugins-only: 1 unit, 1 integration, 0 sanity, 0 molecule1.14 / 3Published artifact
maintenance.release_recencyPassedlast release 37 days ago3 / 3Galaxy index
maintenance.changelog_recencyPartly met1 unreleased changelog fragment0.7 / 1Published artifact
compat.requires_ansiblePassed>=2.17.03 / 3Published artifact
Signals we could not observeNot observed — these are left out of the score rather than counted against it.
trust.ansible_membershipNot observednot shipped in the ansible packageexcluded from this scoreansible-build-data
quality.ciNot observedno CI evidence in the published artifactexcluded from this scorePublished artifact
compat.membership_currencyNot observednot shipped in the ansible packageexcluded from this scoreansible-build-data

No repository evidence yet. ansible.care has not read any collection's Git repository, so every signal above was proved from a published artifact or from Ansible’s own build data. Tests and CI in particular can be proved present this way but never proved absent — so when we cannot see them, we leave them out of the score rather than counting them against you.

What is costing points

Each of these is a signal we observed and could not fully credit.

  • quality.docs

    Ship your README and your `docs/` directory INSIDE the published tarball, not only in your Git repository — we do not read repositories at all yet, so a file that exists only there is a file we cannot see. If your `build_ignore` excludes `docs/`, that exclusion is why we observed nothing. Beyond the README this rule counts documentation FILES, so splitting a long README into per-module and per-role pages is what moves it; adding filler pages to raise a count would satisfy the arithmetic and help nobody.

  • maintenance.changelog_recency

    Write a fragment into `changelogs/fragments/` as each change lands, rather than composing release notes at release time. This reads the same published file as the Quality changelog rule, so shipping and maintaining a changelog answers both at once — if a page told you twice to ship a changelog it would be describing one missing file as two problems. One thing this rule does NOT ask for: an empty fragments directory is not the goal, and cutting a release clears your fragments by design. A maintained changelog with nothing pending still earns partial credit here, so releasing your work does not cost you this rule.

  • trust.link_claims

    Declare the link fields your collection actually has in `galaxy.yml` — `repository`, `documentation`, `homepage` and `issues` — and correct any we reported as unparseable, which is usually a stray character rather than a wrong address. This is a metadata edit: we never fetch what is behind these URLs, so nothing about your hosting is being graded. Do not invent a URL to fill a field — a scaffolding placeholder left where it was born is shown on your page as the placeholder it is, and an honestly empty field reads better than a link that goes nowhere.

What would strengthen this score

These signals can only add points in the current scoring version — they are never counted against you.

  • quality.tests

    Publish your test evidence inside the artifact: `molecule/` scenarios for a role collection, and `tests/unit/`, `tests/integration/` and `tests/sanity/` for a plugin collection. Ansible’s own packaging documentation suggests excluding `tests/` through `build_ignore`, so if you follow that advice we simply cannot see them — their absence from your tarball is a limit on what we read and never a claim that you have no tests. In this scoring version this rule can only add points: when we observe no test evidence the rule leaves your calculation entirely rather than scoring zero, so publishing tests can raise your score and withholding them cannot lower it.

DocumentationNot declared.

Authors

  • Sorin Sbarnea (github/ssbarnea)