Conversation
Nothing in bugbot posted to Slack before this. `bugbot/slack.py` adds the transport on its own, with no caller yet; the first one lands separately. It is one bot for the whole of bugbot. Everything about who is posting lives here -- the token it authenticates with and the name it appears under -- and a caller supplies only the message and where to send it. Where a given rule posts is that rule's business, kept wherever the rest of that rule's configuration is, so a second rule posting somewhere else needs no change here. Messages go through chat.postMessage. That needs a bot token carrying chat:write, and chat:write.public as well to reach a channel the bot has not been invited to. The token is the only secret involved and comes from `slack_bot_token` in configs/config.json or from `SLACK_ACCESS_TOKEN`. A channel ID is not a secret and so does not belong in that file. Messages are posted as "Firefox Release Management Bot". A Slack app's own name is set in its app configuration, is shared by everything the token posts, and is generally not what a reader of one of these messages should see. It is not overridable per call: there is one bot, so there is one name, and letting a rule pick its own would only make bugbot look like several senders. Sending it needs chat:write.customize on the token as well; Slack rejects the message when that scope is missing rather than dropping the name, so it cannot quietly stop working. chat.postMessage reports application errors as HTTP 200 with ok=false, so the body rather than the status is what has to be checked. On missing_scope it names both the scope it wanted and the ones the token carries, which the error passes along because it is very hard to act on otherwise. Nothing is retried, unlike reads: a POST that times out may well have arrived, and retrying it risks posting the message twice.
Ported from mozilla/releases_insights, where this ran as a GitHub Action over anonymous Bugzilla queries. That is the reason for the move: an anonymous search never returns a restricted bug, so every count it posted silently excluded them. Running as bugbot, the same queries see them. Two rules under bugbot/rules, one per message, over the queries and formatting they share in bugbot/reo_regressions.py: - the cycle summary, `reo_regression_slack`, posted Mon and Thu, splitting each channel's open regressions into new and carry over - the action required message, `reo_regression_slack_daily`, ungated and so posted every weekday, listing only the regressions stuck long enough to need a nudge, plus the fixes nobody has asked to uplift The summary decides its two days in the rule rather than in configs/rules.json, as `missed_uplifts` and `workflow.p2_merge_day` decide theirs: the cadence is part of what that message is -- it reports how a cycle is going rather than what has just changed, and says so in its own wording -- so a day added to it in configuration would not make the message any more true. Restricted bugs are counted and linked like any other but never named: no message prints a bug summary, which is the line `BzCleaner.get_summary` draws. The top-level bullet says how many of its count are restricted, because a reader without access opens the link and finds a shorter list than the number they clicked on. One query change worth calling out: `burndown_query` narrows "still marked affected" to the fixes worth chasing, and being in a security group is one of the three ways in. Under anonymous queries that branch matched nothing, so the burndown lines grow here beyond the general restricted-bug increase. Neither rule is a BzCleaner. They run several queries rather than one, report counts rather than a table of bugs, write nothing to Bugzilla, and have to post on a quiet day to say so -- where BzCleaner sends nothing when there are no bugs, and its cache would suppress a bug that must reappear until fixed. They borrow the conventions that do apply: a module per rule in bugbot/rules with the shared parts in a top-level module the way `multinaggers` and `topcrash` hold theirs, a base class rules subclass included, `description`, `must_run(date)` and a name taken from the module file all meaning what they mean there, --production, `logger_extra["bugbot_rule"]`, and the shared helpers for versions, flag names, component teams and search URLs. Testing and Developer Infrastructure are dropped from every query, so their bugs reach neither message and no bucket in either. One ANDed notequals per product rather than a single nowords: Bugzilla splits a nowords value on whitespace, so "Developer Infrastructure" would match as two separate words and drop products nobody asked to exclude. Both rules run from the weekday cron script and post to `CHANNEL`, which is in the code rather than configs/rules.json: it is not a secret, and changing where an unattended recurring message lands should take a code review. CHANNEL is #tmp-dm-test for now, a scratch channel to shake the port out in alongside the messages it replaces. It has to point at the real REO channel before either message is meant for anyone to read.
suhaibmujahid
requested changes
Sep 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Checklist
to-be-announcedtag added if this is worth announcing