middleware_automation.wildfly
Enable Ansible to provisioning JBoss EAP or WildFly instances.
Health score
72 / 100
Healthy, with room to improve.
- Excellent
- Good (this collection)
- Fair
- Poor
- Not scored
Observed 6 of 8 signal groups.
Four are needed before a score is published.
4 needed
Category subscores
- Security
- 0%
- Trust
- 100%
- Quality
- 73%
- Maintenance
- 75%
- ansible-core compatibility
- 85%
| Signal | Verdict | What we found | Points | Proved by |
|---|---|---|---|---|
| Signals we could observe | ||||
| security.dependency_boundedness | Not met | 0 of 2 dependencies bounded | 0 / 1 | Published artifact |
| trust.link_claims | Passed | 4 of 4 link URLs declared | 1 / 1 | Published artifact |
| quality.docs | Partly met | readme, 6 doc files | 2.55 / 3 | Published artifact |
| quality.changelog | Not met | no changelog file, 0 fragments | 0 / 2 | Published artifact |
| quality.license_quality | Passed | SPDX id declared (GPL-2.0-only) | 1 / 1 | Published artifact |
| quality.tests | Passed | roles-only: 0 unit, 0 integration, 0 sanity, 20 molecule | 3 / 3 | Published artifact |
| maintenance.release_recency | Passed | last release 9 days ago | 3 / 3 | Galaxy index |
| maintenance.changelog_recency | Not met | no changelog in the published artifact | 0 / 1 | Published artifact |
| compat.requires_ansible | Partly met | >=2.16.0 | 2.55 / 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 |
| quality.ci | Not observed | no CI evidence in the published artifact | excluded from this score | Published artifact |
| 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.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.
- 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.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.
- compat.requires_ansible
Declare a `requires_ansible` FLOOR in your `galaxy.yml` naming the oldest ansible-core you actually support, and declare an upper bound alongside it if you test against one — the bound is credited on top of whichever floor tier you reach in the table beside this rule. Declaring nothing now scores zero and STAYS in your score rather than dropping out of it, so omitting the field is no longer a way to avoid the question; if your score fell and you have never declared a floor, this is why. An exact pin or a `~=` compatible-release specifier earns only a small share, strictly below every floor tier: it is a real declaration we could read, so it beats silence, and it sits at the bottom because pinning ansible-core is the practice this category exists to discourage. Raising a floor you cannot actually support would be a false declaration, and this rule is not worth that.
Links
Authors
- Romain Pelisse <belaran@redhat.com>
- Andrew Block <ablock@redhat.com>
- Harsha Cherukuri <hcheruku@redhat.com>
- Guido Grazioli <ggraziol@redhat.com>
- Ranabir Chakraborty <rchakrab@redhat.com>