Enhancement: Trigger project status notifications based on scancode-config.yml values

[DennisClark]

See related issue about the scancode-config.yml file: #1197

If a project is created and executed with a scancode-config.yml file, and if that file contains a notification_address, send a notification (email or similar) to that address containing:

• the text of the "run log" normally made available via SCIO UI status field (e.g. "Success")
• all of the links normally made available via SCIO UI buttons associated with "Download results as:" so that the recipient can access those links to obtain those result files.

[tdruez]

@DennisClark I need your help providing the layout and text content of the email notifications.

[tdruez]

@DennisClark I still need your input on the above to make more progress.

[DennisClark]

email subject: Scan results for {project name}

email text:
Project scanned: {project name}
ScanCode.io version: {version}
Scan date: {scan completion timestamp}
Scan status: {status label}
Download log file: {log file link}
Download results as JSON: {JSON link}
Download results as XLXS: {XLXS link}
Download results as SPDX 2.3: {SPDX link}
Download results as CycloneDX 1.4: {CDX 1.4 link}
Download results as CycloneDX 1.5: {CDX 1.5 link}
Download results as CycloneDX 1.6: {CDX 1.6 link}
Download results as Attribution document: {Attribution link}

[DennisClark]

@pombredanne please comment on this from a functionality perspective: do we even need this ? If the results of the command-line scan are written to a specified location anyway, perhaps the next thing to do is to open in ScanCode.io if you want more information. Perhaps an email with the first few elements, down to the log file (perhaps included in the body of the email) would be sufficient.

[tdruez]

This feature would only make sense for a ScanCode.io server setup as it requires an email service provider to be configured.
Also, if the data is not persistent (ie a command line execution) there are no "Download results ...." possible.

We should promote the, already implemented, usage of Webhook over email as it does not require any extra service to be configured and available. We are lacking documentation though, see #1027

[pombredanne]

@DennisClark I agree that we may not need this just now.