Skip to content

pulp.squeezer

Health score

64 / 100

Fair

Usable, but the maintenance or quality evidence is thin.

How bands are set →

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

Observed 4 of 8 signal groups.

Four are needed before a score is published.

4 needed

Category subscores

Security
100%
Trust
30%
Quality
33%
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.link_claimsPartly met1 of 4 link URLs declared0.3 / 1Published artifact
quality.docsPartly metreadme, 0 doc files1.5 / 3Published artifact
quality.changelogNot metno changelog file, 0 fragments0 / 2Published artifact
quality.license_qualityPartly metlicense file declared, no SPDX id0.45 / 1Published artifact
maintenance.release_recencyPassedlast release 59 days ago3 / 3Galaxy index
maintenance.changelog_recencyNot metno changelog in the published artifact0 / 1Published artifact
compat.requires_ansiblePassed>=2.16.0,<2.223 / 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.testsNot observedno test evidence in the published artifactexcluded from this scorePublished artifact
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.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.

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

DocumentationNot declared.
HomepageNot declared.
IssuesNot declared.

Authors

  • Matthias Dellweg <2500@gmx.de>
  • Timo Funke <timoses@msn.com>
  • Jacob Floyd <cognifloyd@gmail.com>
  • Yanis Guenane <yguenane@redhat.com>
  • Evgeni Golov <evgeni@golov.de>
  • Hamed Abdelli <abdelli.hamed@yahoo.fr>
  • Piotr Parczewski <piotr@stackhpc.com>
  • keilr <remy.keil@gmail.com>
  • Mark Goddard <mark@stackhpc.com>
  • Daniel Ziegenberg <daniel@ziegenberg.at>
  • Alex Welsh <alex@stackhpc.com>
  • ajsween <ajsween@gmail.com>
  • Christian Loos <cloos@netsandbox.de>
  • Kevin P. Fleming <kevin@km6g.us>
  • Alessandro Taufer <alexander141220@gmail.com>
  • Chris Taylor <taylorcw@gmail.com>
  • Stefan Joosten <stefan@atcomputing.nl>
  • Maciej Markowski <maciekmm@o2.pl>