dalibo.essential
The Dalibo Essential Collections is a set of Ansible roles for the Dalibo Postgres Platform.
Health score
89 / 100
Strong evidence across everything we could observe.
- Excellent (this collection)
- Good
- Fair
- Poor
- Not scored
Observed 7 of 8 signal groups.
Four are needed before a score is published.
4 needed
Category subscores
- Security
- 100%
- Trust
- 85%
- Quality
- 75%
- Maintenance
- 93%
- ansible-core compatibility
- 100%
| Signal | Verdict | What we found | Points | Proved by |
|---|---|---|---|---|
| Signals we could observe | ||||
| security.dependency_boundedness | Passed | no dependencies declared | 1 / 1 | Published artifact |
| trust.link_claims | Partly met | 3 of 4 link URLs declared | 0.85 / 1 | Published artifact |
| quality.docs | Partly met | readme, 0 doc files | 1.5 / 3 | Published artifact |
| quality.changelog | Passed | changelog.yaml, 1 fragment | 2 / 2 | Published artifact |
| quality.license_quality | Passed | SPDX id declared (GPL-3.0-or-later) | 1 / 1 | Published artifact |
| quality.tests | Passed | roles-only: 0 unit, 0 integration, 0 sanity, 14 molecule | 3 / 3 | Published artifact |
| quality.ci | Partly met | 0 workflow files, 1 other CI file | 0.8 / 2 | Published artifact |
| maintenance.release_recency | Passed | last release 127 days ago | 3 / 3 | Galaxy index |
| maintenance.changelog_recency | Partly met | 1 unreleased changelog fragment | 0.7 / 1 | Published artifact |
| compat.requires_ansible | Passed | >=2.19.0 | 3 / 3 | Published artifact |
| Signals we could not observeNot observed — these are left out of the score rather than counted against it. | ||||
| trust.ansible_membership | Not observed | not shipped in the ansible package | excluded from this score | ansible-build-data |
| compat.membership_currency | Not observed | not shipped in the ansible package | excluded from this score | ansible-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.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.
Links
Authors
- DALIBO SCOP <contact@dalibo.com> (https://www.dalibo.com)