CKI-003: Reports recipients rules
While working to improve and simplify the reporter automations, the problem of dynamically defining the list of recipients for a report resurged.
After several discussions, the decision of extracting that responsibility from the reporter was taken, creating the need for a new place where to define this data.
This proposal is intended to simplify the current decisions taking algorithm, aspiring to a simpler reporter service by making the list of recipients more explicit, reproducible and testable.
The current system makes it impossible to identify who is going to receive a report without running the code. The result of this change needs to fix that.
While testing a revision, the maintainers of this tree need to receive the results of the tests. Then can decide to get only failure notifications or also success ones.
When tests fail, maintainers for those tests need to be informed of the failures.
Internal results list
The internal testing results list needs to receive all the reports sent, always.
Gate keeping reports from reaching consumers need to be possible. Gated results should override all the recipients and only be sent to the manual reviewers.
This list of reviewers is kept separated from the list of recipients and it overrides them in case that a revision needs to be reviewed and the review has not happened yet.
The pipeline ‘review’ job notifies DataWarehouse that a revision’s results were reviewed and the reviewer recipients list is replaced with the real recipients.
KCIDB schema defines a list of contacts as:
List of e-mail addresses of contacts concerned with this revision, such as authors, reviewers, and mail list
Currently this list is populated only with the brew task submitters. These should be treated as tree maintainers.
Define static rules
Using a syntax similar to Gitlab rules, define the reporting rules for each tree on the pipeline-data definitions.
--- tree: report-rules: - if: [and-conditions] send_to: [recipients] send_cc: [recipients] send_bcc: [recipients]
By using YAML anchors, powered by CKI’s config tree, define default rules and allow per-tree configurations.
--- .rule-foo: &rule-foo if: foo send_to: foo .rule-bar: &rule-bar if: bar send_cc: bar .rules-generic: &rules-generic - *rule-foo - *rule-bar tree-1: report-rules: *rules-generic tree-2: report-rules: - *rule-foo
Use reserved keywords to represent groups of recipients, such as
submitter, etc. and conditions of the results, i.e
--- tree: report-rules: - if: success send_to: submitter - if: failed_tests send_cc: failed_tests_maintainers - if: always send_bcc: email@example.com
All the rules must be evaluated and the final recipients list be the result of merging each rule’s outcome.
Single source of truth
These rules must define the final list of recipients (or groups of recipients) for a pipeline.
If a certain tree has no rules configured, that tree should have no reports sent.
- submitter: The submitter of the patch.
- failed_tests_maintainers: Maintainers of the failed tests.
- origin: An email/mailing list for the tested git tree.
- subscribers: Emails that have subscribed to this tree/revision via Datawarehouse.
- success: On overall success of the pipeline.
- failed: On overall failure of the pipeline (if any step of the pipeline fails).
- failed_tests: For when the pipeline fails in the testing step.
Recipient target keywords
- override_ignore: A list of recipients that will be filtered from all other fields before sending.
The resulting rules need to be easy to read for humans and parse by machines, allowing us to understand the recipients by simple observation.
By using keywords for recipients groups, like
the translation of these rules into email addresses needs to be done by the
piece of code evaluating them.
This also generates the need to have keywords synchronized between the definition and the parsers.