Description
We'll need a new on_version_scanned event in the scanner pipeline.
- This event should be executed after all scanners hooked to
on_version_created have returned their results
- The payload for this event should contain all the scanner results available for the version at the time of firing this event
- Scanners hooked to this event should block auto-approval
Here is how I'd document this event in the scanner pipeline docs:
This event occurs once every scanner listening to on_version_created has
returned its results for the version, whether it returned them synchronously,
asynchronously, or skipped the event. It is meant for scanners that need to make a
decision informed by what the other scanners found.
In addition to the usual addon and version properties, the payload contains a
scanner_results object mapping the name of each scanner listening to
on_version_created to the results it returned. A null value means that
scanner skipped the event.
{
"addon": {
// Similar to the `on_version_created` event.
},
"version": {
// Similar to the `on_version_created` event.
},
"scanner_results": {
"some-scanner": {
"version": "1.0",
"matchedRules": ["SOME_RULE"],
"annotations": {}
},
"some-other-scanner": null
},
"event": "on_version_scanned",
"scanner_result_url": "http://olympia.test/api/v5/scanner/results/126/"
}
Note: When no scanner is listening to on_version_created, this event is still sent,
with an empty scanner_results object.
Two things are tied to this event:
- Like
during_validation and on_version_created, it blocks auto-approval:
a version is not auto-approved until every scanner listening to it has returned
its results. When that takes longer than WAIT_ON_SCANNERS_TIMEOUT, the version
is flagged for human review instead.
- The scanner actions for the version are executed once this event completes, i.e.
when the whole pipeline is done and all the results are known.
Acceptance Criteria
see above
┆Issue is synchronized with this Jira Task
Description
We'll need a new
on_version_scannedevent in the scanner pipeline.on_version_createdhave returned their resultsHere is how I'd document this event in the scanner pipeline docs:
This event occurs once every scanner listening to
on_version_createdhasreturned its results for the version, whether it returned them synchronously,
asynchronously, or skipped the event. It is meant for scanners that need to make a
decision informed by what the other scanners found.
In addition to the usual
addonandversionproperties, the payload contains ascanner_resultsobject mapping the name of each scanner listening toon_version_createdto the results it returned. Anullvalue means thatscanner skipped the event.
{ "addon": { // Similar to the `on_version_created` event. }, "version": { // Similar to the `on_version_created` event. }, "scanner_results": { "some-scanner": { "version": "1.0", "matchedRules": ["SOME_RULE"], "annotations": {} }, "some-other-scanner": null }, "event": "on_version_scanned", "scanner_result_url": "http://olympia.test/api/v5/scanner/results/126/" }Note: When no scanner is listening to
on_version_created, this event is still sent,with an empty
scanner_resultsobject.Two things are tied to this event:
during_validationandon_version_created, it blocks auto-approval:a version is not auto-approved until every scanner listening to it has returned
its results. When that takes longer than
WAIT_ON_SCANNERS_TIMEOUT, the versionis flagged for human review instead.
when the whole pipeline is done and all the results are known.
Acceptance Criteria
see above
┆Issue is synchronized with this Jira Task