Skip to content

infinidat.infinibox

A set of Ansible modules that allow simple, but powerful, idempotent interactions with Infinidat Infiniboxes.

Health score

76 / 100

Good

Healthy, with room to improve.

How bands are set →

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

Observed 5 of 8 signal groups.

Four are needed before a score is published.

4 needed

Category subscores

Security
100%
Trust
87%
Quality
49%
Maintenance
75%
ansible-core compatibility
100%
Every signal we evaluated for this collection
Signals we could observe
security.dependency_boundednessPassedno dependencies declared1 / 1Published artifact
trust.ansible_membershipPassedships in 12 ansible package majors2 / 2ansible-build-data
trust.link_claimsPartly met2 of 4 link URLs declared0.6 / 1Published artifact
quality.docsPartly metreadme, 2 doc files2.1 / 3Published artifact
quality.changelogNot metno changelog file, 0 fragments0 / 2Published artifact
quality.license_qualityPassedSPDX id declared (GPL-3.0-or-later)1 / 1Published artifact
quality.ciPartly met0 workflow files, 1 other CI file0.8 / 2Published artifact
maintenance.release_recencyPassedlast release 1 days ago3 / 3Galaxy index
maintenance.changelog_recencyNot metno changelog in the published artifact0 / 1Published artifact
compat.requires_ansiblePassed>=2.18.03 / 3Published artifact
compat.membership_currencyPassedships in ansible 14 (current is 12)1 / 1ansible-build-data
Signals we could not observeNot observed — these are left out of the score rather than counted against it.
quality.testsNot observedno test evidence in the published artifactexcluded from this scorePublished artifact

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

    Ship a `changelogs/changelog.yaml` — the structured form `antsibull-changelog` generates and the `ansible` package consumes — rather than only a hand-maintained `CHANGELOG.md`, and write a fragment into `changelogs/fragments/` as each change lands rather than reconstructing release notes at release time. Both have to be inside the published tarball to be observable: a changelog that lives only in your Git repository is one we cannot read. This is the single highest-leverage change for most collections, because the same missing file is what holds down both changelog rules in this rubric. If you already publish `changelog.yaml` with fragments, this rule is answered.

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

  • 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.ci

    Publish your CI configuration inside the artifact. `.github/workflows/` is what we count most precisely, and other CI config files earn partial credit when your automation runs somewhere we cannot enumerate as exactly. `build_ignore` commonly strips `.github/`, again on the packaging documentation’s own advice, so an absence here is a gap in what we could read rather than a statement that your collection has no CI. In this scoring version this rule can only add points: an unobserved CI signal leaves your calculation rather than scoring zero, so this is worth doing for the credit and never to avoid a deduction.

DocumentationNot declared.
HomepageNot declared.

Authors

  • Infinidat <partners.infi@infinidat.com>
  • David Ohlemacher
  • Gregory Shulov