Add optional TRIGGERED_BY_EMAIL to mention who triggered the build - #9
Merged
Merged
Conversation
Commits are not always made by a person. On GitHub, squash merges and merge commits made through the web UI are committed as `GitHub <noreply@github.com>`, and the author is whoever opened the pull request - which can itself be a bot. In that case neither of the two identities in the approval message points at the person waiting on the deploy, so nobody gets mentioned. Let CI pass that identity in via the new optional TRIGGERED_BY_EMAIL variable. When set, a `Triggered by` line is added to the message, mentioning the person if the email matches a Slack profile and falling back to the plain email if it does not - same behaviour as the existing committer and author lines. When it is unset, the message is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
yousefdebaz-fivexlio
force-pushed
the
feat/triggered-by-email-internal
branch
from
August 13, 2026 22:42
d104ac1 to
4c8d09b
Compare
AI Code Review Summary
This summary was automatically generated by the AI code review workflow. |
- Reject whitespace-only TRIGGERED_BY_EMAIL, not just empty string - Suppress the Triggered by line entirely for GitHub noreply addresses (bare noreply@github.com and the privacy-enabled <id>+<user>@users.noreply.github.com form), since neither resolves to a real person - Log Slack lookup failures instead of failing silently
…lack The whitespace guard validated the stripped value but kept using the raw one, so a padded-but-valid address still broke: the Slack lookup was sent ' user@example.com ', missed, and the fallback printed the address with its surrounding whitespace - the same failure the review described, just with a non-empty address. Strip at the source instead. That also lets the guard collapse into one plain condition, since is_noreply_email() already strips and lowercases internally and the extra .strip() was redundant. Move is_noreply_email() and its constants from helpers_git to helpers_slack. Classifying an address is not a git operation; the question it answers is whether the address can resolve to a Slack profile, which is what the rest of helpers_slack is about. helpers_git also imports helpers_slack, so keeping email logic there deepens that import cycle for no reason. Verified: flake8 and pylint -E clean per lint.sh. Rendered the details block through main.py with Slack and git stubbed - a padded address now resolves to a mention where it previously printed raw, unresolvable and noreply addresses behave as before, and with the variable unset the block is byte-for-byte identical to master. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Same-repo mirror of #7 (#7 from AndreiHippo:feat/triggered-by-email), opened so the AI code review workflow can run on it - fork PRs are excluded by design (see #8).
Original description from #7:
Problem
The approval message identifies two people: the commits committer and its author. Neither is reliably a person. On GitHub, every commit created by the platform itself - squash merges, merge commits, rebase merges, web-editor edits, API-created commits - is committed as
GitHub <noreply@github.com>. On a protected branch that only ever receives merges through the merge button, that is every commit. The author is whoever opened the pull request, which is often a bot (Dependabot, a code-review app). So an approval request can arrive with no human mentioned at all, even though a person just pressed Merge and is waiting on the deploy.Change
A new optional
TRIGGERED_BY_EMAILvariable. When set, aTriggered byline is added to the details block, resolving the email to a Slack mention and falling back to the plain email - the same treatment the committer and author lines already get. When unset, the message is byte-for-byte what it is today.Testing
flake8andpylint -Eclean, perlint.sh.main.pywith Slack and git stubbed, across all three paths: email resolvable in Slack (mention), email unknown to Slack (plain-text fallback), and variable unset (unchanged output).Credit: AndreiHippo. Close #7 once this merges (or supersede it).