Feature Request: Make it easier to communicate compliance failures to pinning service providers

[SgtPooki]

In order to keep manual effort to a minimum, we should automate communication of compliance failures as much as possible. There are a few methods I've thought about to accomplish this:

• After a report is run, if there are compliance check failures, email the pinning service provider with a link to the report.
• Inside each report there should be a link for "submitting an issue" to the appropriate pinning service provider that would prefill the appropriate information
  • Should we create an issue link for each compliance check failure or a single one for each report?
• We should have a POC for each pinning service added to the compliance checker, so we can tag them on discussions like https://github.com/ipfs-shipyard/pinning-service-compliance/issues/124 and THIS issue.

---

Pinning service provider repos and/or URLs:

• Estuary
  • https://github.com/application-research/estuary/issues
• nft.storage
  • https://github.com/nftstorage/nft.storage/issues
• Pinata
  • https://github.com/ipfs/pinning-services-api-spec/issues
• web3.storage
  • https://github.com/web3-storage/web3.storage/issues

[SgtPooki]

Got a response from Pinata:

hey [ @SgtPooki ] we don’t have an official place for this right now, but an issue on the actual pinning services spec repo might be helpful here - @obo20

Also related is #140 so that services could add checks into their CI/CD workflow.

[SgtPooki]

@lidel are you cool with me opening pinning compliance issues for Pinata on the spec repo, or should I open them here?

[SgtPooki]

For now, we're going to point providers towards https://github.com/ipfs-shipyard/pinning-service-compliance/issues/140, and have them handle their own destiny. We will, as a one-time only thing, open a single issue in the appropriate repositories to let providers know of any failures, but after that it will be up to providers to handle the aforementioned destiny.

[lidel]

@SgtPooki I think your approach is sensible :+1:

Providing NPM package that pinning services can run on their own is more than enough to run in any CI setup services have:

npx @ipfs-shipyard/pinning-service-compliance -s <endpoint> <auth>

I like the idea of going the extra mile and doing one-time ping + providing Github Action (#140) , but don't think we should be doing more handholding than that :-)

[SgtPooki]

Cool thanks for the second set of eyes :)