Introducing the Red Hat partner certification checker

We’re pleased to announce a new tool to help Red Hat partners get collections certified on Ansible Automation Hub!

When sanity or lint tests fail during the Automation Hub import process, collection uploads are rejected. This means Red Hat partners need to address the issues and resubmit their collections for certification, which adds development and release cycles.

To help Red Hat partners catch common issues, the partner-certification-checker provides a workflow that runs in GitHub Actions and checks collections against minimum certification requirements. The certification checker runs those sanity and lint tests in CI pipelines so Red Hat partners can identify and fix issues before uploading to Automation Hub.

The Ansible Community and Partner Engineering team at Red Hat will also maintain the certification checker by pinning package versions to align with the import process. This gives Red Hat partners increased visibility into the specific sanity and lint tests that run when uploading collections to Automation Hub. Furthermore the partner-certification-checker offers the option for a self-managed workflow if you prefer to customize the checks and maintain your own version matrix.

Getting started

To start using the certification checker, all you need to do is copy the certification workflow to your .github/workflows directory.

For complete instructions, see the certification checker README.

Give us your feedback

If you run into issues or have suggestions on how to improve the certification checker, open an issue in the partner-certification-checker repository or reply to this thread.

1 Like

Is certification checker passed required or sufficient to have ansible collection certified? Obviously there is partner agreement that has to be signed, I mean from technical standpoint.

I think it is worth mentioning what lint and sanity checks that cannot be skipped, ignored and what can be. Because at the moment nothing stops anyone just adding ansible-lint config that skips all and sanity ignore files and ignore all.
Another option would be for this workflow to ignore repo’s lint and sanity configuration at all and use its own.

1 Like

Is certification checker passed required or sufficient to have ansible collection certified? Obviously there is partner agreement that has to be signed, I mean from technical standpoint.

No, there are other checks and requirements to get certified. You can see most of them in the certification workflow guide.

We are planning to update and improve the documentation to make the certification process more transparent to partners and the rest of the community. That is partly the inspiration for the checker workflow.

When you upload a collection to Automation Hub it goes through a galaxy-importer run that is pinned to specific versions of core and lint. If you don’t have any checks pinned to those same versions, it can be a shot in the dark as to whether your collection will hit issues or not.

I think it is worth mentioning what lint and sanity checks that cannot be skipped, ignored and what can be.

We do mention the current list of allowed sanity ignores in the README.

For lint rules, it can depend. If a collection has some lint violations that are more related to code quality, for instance rules in the min and basic profiles, we typically follow up with partners to bring those issues to their attention and require them to be addressed in the subsequent release. That is if no other substantial issues are observed.

Lint violations such as risky file permissions would result in the upload being rejected. If you don’t set mode on file operations then it relies on whatever the umask is for the target node, which is non-deterministic behaviour and can leave security holes. The majority of collections that are submitted for certification are linted before release though so it’s not typical to encounter such lint violations.

Because at the moment nothing stops anyone just adding ansible-lint config that skips all and sanity ignore files and ignore all.

During collection review we also check for the presence of things like skip lists and excludes in lint configuration.

Another option would be for this workflow to ignore repo’s lint and sanity configuration at all and use its own.

Yes but I think that diverges from the point a little. That’s not something that happens in galaxy-importer and the purpose is to give folks visibility into what will happen when their collections are imported into Automation Hub. If we wanted to add the option to ignore repo configuration, it should happen in galaxy-importer imo.

1 Like