shahargolshani.test_itsi
Ansible Collection for Splunk IT Service Intelligence
Health score
85 / 100
Strong evidence across everything we could observe.
- Excellent (this collection)
- Good
- Fair
- Poor
- Not scored
Observed 8 of 8 signal groups.
Four are needed before a score is published.
4 needed
Category subscores
- Security
- 0%
- Trust
- 100%
- Quality
- 85%
- Maintenance
- 100%
- ansible-core compatibility
- 100%
| Signal | Verdict | What we found | Points | Proved by |
|---|---|---|---|---|
| Signals we could observe | ||||
| security.dependency_boundedness | Not met | 0 of 1 dependencies bounded | 0 / 1 | Published artifact |
| trust.link_claims | Passed | 4 of 4 link URLs declared | 1 / 1 | Published artifact |
| quality.docs | Passed | readme, 12 doc files | 3 / 3 | Published artifact |
| quality.changelog | Passed | changelog.yaml, 10 fragments | 2 / 2 | Published artifact |
| quality.license_quality | Partly met | license file declared, no SPDX id | 0.45 / 1 | Published artifact |
| quality.tests | Partly met | plugins-only: 14 unit, 45 integration, 0 sanity, 0 molecule | 2.25 / 3 | Published artifact |
| quality.ci | Partly met | 4 workflow files, 0 other CI files | 1.6 / 2 | Published artifact |
| maintenance.release_recency | Passed | last release 162 days ago | 3 / 3 | Galaxy index |
| maintenance.changelog_recency | Passed | 10 unreleased changelog fragments | 1 / 1 | Published artifact |
| compat.requires_ansible | Passed | >=2.17.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.
- security.dependency_boundedness
Give every collection dependency you declare in `galaxy.yml` an upper or pinned bound — `<`, `<=`, `==` or `~=` — so that installing your collection cannot silently pull in an arbitrary future release of somebody else’s. If your collection declares no dependencies at all this rule already awards full marks and there is nothing here to change. If we reported a dependency we could not read, the fix is the syntax of its version range rather than the dependency itself.
- quality.license_quality
Declare a machine-readable SPDX identifier in `galaxy.yml`’s `license` field rather than relying on a `LICENSE` file alone: an identifier is what a consuming organisation’s policy tooling reads without a human opening the file. A `LICENSES/` directory following REUSE ranks above a bare root licence file and below the identifier. One exception worth stating: we record the identifier you publish rather than validating it against the SPDX list, so a wrong identifier will earn these marks and mislead your users at the same time — if no SPDX identifier fits your licence, publish the file instead.
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.
- 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
- Ansible Ecosystem Engineering team
- Shahar Golshani <sgolshan@redhat.com>
- Ron Gershburg <rgershbu@redhat.com>