Skip to content

feat(notifications): send subscribed new-issues summaries - #2175

Draft
felipebergamin wants to merge 6 commits into
kernelci:mainfrom
profusion:feat/new-issues-subscribed-summaries
Draft

felipebergamin wants to merge 6 commits into
kernelci:mainfrom
profusion:feat/new-issues-subscribed-summaries

Conversation

@felipebergamin

Copy link
Copy Markdown
Member

Summary

Part of #2115. Depends on #2159 (#2114). This branch is based on #2159, so its two schema commits show here until that PR merges. Review the last three commits for this change.

  • Add an optional new_issues.issue_types block to a subscription recipient. The hourly job sends that address one filtered copy of the new-issues summary. Tree scope is the git URL. Hardware scope is the platform and origin. No block means no extra mail.
  • The community summary stays one message, to the command's To, with every new build and boot issue. It reuses issues.txt.j2 and the notifications_issue dedup. test issues are stored and mailed only for a copy that lists test.
  • Replace the hardcoded maestro + build regression trigger with --issue-report-origins (default maestro) and --issue-report-types (default build). The cron is unchanged. Regression To, Cc, and regzbot recipients are unchanged. issue_report --all still sends build only.

The issues list from #2159 still records the [REGRESSION] mail only. It does not subscribe anyone to the summary. No current YAML has a new_issues block, so production sends the same mail until a PR adds one.

An issue is matched through its first incident, the same row the community summary already prints. With --send left off, the command prints To and the issue ids for the community mail and for each copy that has a match.

Test plan

From backend/:

  • poetry run pytest kernelCI_app/tests/unitTests/commands/notification_subscriptions_test.py kernelCI_app/tests/unitTests/commands/new_issues_notifications_test.py kernelCI_app/tests/unitTests/queries/notifications_test.py
  • poetry run python manage.py notifications --action new_issues (no --send). Confirm one To line for the community summary and the issue ids.
  • Add a temporary new_issues block for one tree address, rerun the same command, and confirm a second To line only when that tree has a matching issue. Remove the block afterward.
  • poetry run python manage.py notifications --action new_issues --issue-report-types boot and confirm the only automatic regression reports are boot issues from maestro. Leave --send off.

Made with Cursor

alanpeixinho and others added 6 commits October 7, 2026 20:46
* Accept an address string or an email mapping with an issues list
* Record issues: [build] on every tree recipient, the regression mail they already receive
* Leave hardware recipients as plain addresses
* Validate subscription and metrics files in CI, with errors that name the file and field
* Keep the send path Cc'ing the same addresses

Part of kernelci#2114

Signed-off-by: Alan Peixinho <[email protected]>
Treat an address string as the same recipient as an email mapping, so a bad address fails on the email field.

Part of kernelci#2114

Signed-off-by: Alan Peixinho <[email protected]>
Record an optional new_issues.issue_types list on a recipient without changing who is Cc'd. Plain addresses and the existing issues list do not opt into the hourly summary.

Part of kernelci#2115

Assisted-by: Grok 4.7 <[email protected]>
Signed-off-by: Felipe Bergamin <[email protected]>
Co-authored-by: Cursor <[email protected]>
Send one hourly copy per new_issues block, limited to that file's tree or hardware and to the listed issue types. The community summary stays a single build and boot mail, and addresses without the block are unchanged.

Part of kernelci#2115

Assisted-by: Grok 4.7 <[email protected]>
Signed-off-by: Felipe Bergamin <[email protected]>
Co-authored-by: Cursor <[email protected]>
Replace the hardcoded maestro and build-only trigger on the hourly job with --issue-report-origins and --issue-report-types. Defaults stay maestro and build, so the cron sends the same regression reports.

Part of kernelci#2115

Assisted-by: Grok 4.7 <[email protected]>
Signed-off-by: Felipe Bergamin <[email protected]>
Co-authored-by: Cursor <[email protected]>
Drop the new_issues block. boot and test on the existing issues list request the hourly filtered summary. build stays the regression mail, so current files send no extra copy.

Part of kernelci#2115

Assisted-by: Grok 4.7 <[email protected]>
Signed-off-by: Felipe Bergamin <[email protected]>
Co-authored-by: Cursor <[email protected]>
return new_issues


def _tag_new_issues(issues: list[dict], *, test_only: bool = False) -> list[dict]:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be wrong, but arent we marking also builds with type test here?
We could go with something like

  if wants_test:
      known = {issue["id"] for issue in summary_issues}
      for issue in kcidb_new_issues(include_other_tests=True):
          if issue["id"] in known or issue["build_id"] or not issue["test_id"]:
              continue
          issue["type"] = "test"
          summary_issues.append(issue)

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants