Refine Webhook trigger event

[tdruez]

See discussion at #1320 (comment)

We need more control on event that trigger the Webhooks.

Also time to revisit #466 and add docs #1027

[JonoYang]

Currently, the webhook posts the project information and links to the results and summary. I think it would be good to have an option to send the entire results and summary when sending the webhook subscription. This would help in the context of using scancode.io as a purldb scan worker. We can set up multiple workers and give them an access key to purldb and they can get packages to scan and send back the results without requiring purldb to have access back to the scan workers to collect the scans. This simplifies setup for workers as we do not need to have the workers accessible from the internet, they just need to be able to connect to the purldb. We would be able to add more workers to purldb without any input on the purldb side.

[pombredanne]

If we use more webhooks, I can see how having the possibility to have two web hooks can help: for instance, the scan is sent back to PurlDB and also DejaCode

[tdruez]

@JonoYang See #1338 for the new Webhook system.

[tdruez]

The current state from #1338 was merged.

There are still a few improvements required:

• Add the ability to add/edit/delete Webhook from the UI (project settings)
• Documentation
• Add support for providing authentication credentials, Webhook behavior customization and delivery records #1338 (review)

See also https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries and https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks

[tdruez]

@JonoYang Here's how the callback using webhook is handled in DejaCode:

• https://github.com/nexB/dejacode/blob/main/dejacode_toolkit/scancodeio.py#L65
• https://github.com/nexB/dejacode/blob/main/dejacode_toolkit/scancodeio.py#L421
• https://github.com/nexB/dejacode/blob/main/product_portfolio/views.py#L2052

I think in your case, the Webhook cannot directly callback the main PurlDB app but should instead callback the worker that would send the data to the main PurlDB (as the worker can authenticate with its API KEY)