chore(ci): repoint push-email-notify to smtp-notify-action #68
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,19 +4,43 @@ | |
| # PUSH_EMAIL_ENABLED=true (the single on/off switch). Addresses are pre-filled; | ||
| # sending needs the org SMTP secrets (SMTP_HOST/PORT/USER/PASS). Inherited by | ||
| # new repos from the template; placed on existing repos by the farm sweep. | ||
| # | ||
| # Re-landed after the 2026-07-20 notification-storm freeze (removed in | ||
| # 09f94c5), now on hyperpolymath/smtp-notify-action: Node-free, the SMTP | ||
| # session is Idris2-specified and machine-checked, the binary is Zig-built, | ||
| # byte-reproducible, and SHA-256-pinned inside the action itself. | ||
| name: Push email notification | ||
| on: | ||
| push: | ||
| # Branch pushes only: tag and deletion payloads mislabel Branch:/head_commit. | ||
| branches: ['**'] | ||
| concurrency: | ||
| # Deliberately per-RUN, so no run is ever queued behind another and none is | ||
| # ever cancelled. Do NOT "tidy" this into a shared group such as | ||
| # ${{ github.workflow }}-${{ github.ref }}. GitHub's workflow-syntax docs: | ||
| # "By default, any existing pending job or workflow in the same concurrency | ||
| # group will be canceled and the new queued job or workflow will take its | ||
| # place." That happens regardless of cancel-in-progress, which governs only | ||
| # the RUNNING job. On this workflow it silently loses a notification email, | ||
| # with no error anywhere. Every run here reports a DISTINCT commit, so there | ||
| # is no redundant work for a concurrency limit to remove. | ||
| # The docs also offer `queue: max` (up to 100 pending); not used, because 100 | ||
| # is still a cap whereas a per-run group needs none. | ||
| # Verified with zizmor 1.30.0: deleting this block raises concurrency-limits; | ||
| # this form silences it exactly as a shared group would. | ||
| group: push-email-${{ github.run_id }} | ||
| cancel-in-progress: false | ||
| permissions: | ||
| contents: read | ||
| jobs: | ||
| notify: | ||
| name: Email on push | ||
| if: ${{ vars.PUSH_EMAIL_ENABLED == 'true' }} | ||
| runs-on: ubuntu-latest | ||
| timeout-minutes: 5 | ||
| steps: | ||
| - name: Send push notification email | ||
| uses: hyperpolymath/smtp-notify-action@v0.2.0 # NOSONAR — pin authority is actions.lock (sha1-ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7) | ||
|
There was a problem hiding this comment. 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- workflow ---'
cat -n .github/workflows/push-email-notify.yml
printf '%s\n' '--- related lock references ---'
rg -n -C 2 'smtp-notify-action|SMTP_PORT|SMTP_HOST|SMTP_SECURE|secure:' .github actions.lock* . 2>/dev/null | head -200Repository: hyperpolymath/wordpress-tools Length of output: 6114 🤖 get_repo_knowledge executed:
Length of output: 11429 🌐 Web query:
💡 Result: Regarding the query about smtp-notify-action v0.2.0, there is no widely recognized technical project by that specific name (hyperpolymath/smtp-notify-action) in the context of a public migration guide. It is possible that this refers to a private repository, a misremembered name, or a component within a larger system like those used in the hyperpolymath GitHub organization [1][2]. However, the technical challenges mentioned—secure AUTH PLAIN, implicit TLS, STARTTLS, and Microsoft 365 compatibility—are common integration issues [3][4]. When configuring SMTP services with Microsoft 365, consider the following authoritative requirements [5][6][7]: 1. Microsoft 365 Requirements: - Authenticated SMTP must be explicitly enabled in the Microsoft 365 Admin Center for the specific mailbox [3]. - Use smtp.office365.com on port 587 with STARTTLS [6][7]. - Microsoft 365 often prefers AUTH LOGIN over AUTH PLAIN [3]. If your library or action is hardcoded to use PLAIN, it may fail with a 504 5.7.4 error; ensure the client negotiates authentication based on server capabilities [3]. - Modern authentication (OAuth 2.0) is increasingly required [5][4]; basic authentication (username/password) may be disabled by tenant-wide security defaults or Conditional Access policies [5][3]. 2. General SMTP Best Practices: - Implicit TLS (port 465) is generally preferred over STARTTLS (port 587) for security as it avoids the potential for downgrade attacks, though Microsoft 365 standard client submission specifically requires port 587 with STARTTLS [4][6][7]. - Never store credentials in source code; use GitHub Secrets or equivalent environment variables [1][4][8][9]. - If you are encountering migration issues, verify that your client library or action correctly handles the TLS handshake sequence (STARTTLS vs. implicit) and supports the authentication mechanisms advertised by the server [3][4][6]. Citations:
🏁 Script executed: #!/bin/bash
set -u
base='https://github.com/ghraw/hyperpolymath/smtp-notify-action/v0.2.0'
for path in action.yml action.yaml MIGRATION.adoc README.md; do
printf '\n--- %s ---\n' "$path"
curl -L --fail --silent --show-error --max-time 15 "$base/$path" || true
done
printf '\n--- tag metadata ---\n'
curl -L --fail --silent --show-error --max-time 15 \
'https://github.com/ghapi/repos/hyperpolymath/smtp-notify-action/git/ref/tags/v0.2.0' || trueRepository: hyperpolymath/wordpress-tools Length of output: 16302 Verify the SMTP endpoint before enabling this migration.
🤖 Prompt for AI AgentsSource: MCP tools 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: printf '%s\n' '--- workflow ---'
sed -n '35,48p' .github/workflows/push-email-notify.yml
printf '%s\n' '--- lock entry ---'
rg -n -C 2 'smtp-notify-action|ede1191|v0\.2\.0' .github/workflows/actions.lock
printf '%s\n' '--- repository files ---'
git ls-files .github/workflows
printf '%s\n' '--- GitHub API resolution ---'
python3 - <<'PY'
import json
import urllib.request
base = "https://github.com/ghapi/repos/hyperpolymath/smtp-notify-action"
for path in ("/git/ref/tags/v0.2.0", "/commits/ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7"):
req = urllib.request.Request(base + path, headers={"Accept": "application/vnd.github+json", "User-Agent": "review-verifier"})
try:
with urllib.request.urlopen(req, timeout=10) as response:
print(path, response.status)
print(json.dumps(json.load(response), separators=(",", ":")))
except Exception as exc:
print(path, type(exc).__name__, str(exc))
PYRepository: hyperpolymath/wordpress-tools Length of output: 2083 🤖 get_repo_knowledge executed:
Length of output: 22198 🏁 Script executed: python3 - <<'PY'
import json
import urllib.request
import ssl
base = "https://github.com/ghapi/repos/hyperpolymath/smtp-notify-action"
ctx = ssl._create_unverified_context()
def get(path):
req = urllib.request.Request(
base + path,
headers={"Accept": "application/vnd.github+json", "User-Agent": "review-verifier"},
)
with urllib.request.urlopen(req, timeout=15, context=ctx) as response:
return json.load(response)
ref = get("/git/ref/tags/v0.2.0")
obj = ref["object"]
print("tag_ref:", json.dumps(obj, sort_keys=True))
if obj["type"] == "tag":
tag = get("/git/tags/" + obj["sha"])
resolved_sha = tag["object"]["sha"]
print("annotated_tag_target:", json.dumps(tag["object"], sort_keys=True))
else:
resolved_sha = obj["sha"]
print("resolved_commit:", get("/commits/" + resolved_sha)["sha"])
candidate = "ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7"
try:
print("candidate_commit:", get("/commits/" + candidate)["sha"])
except Exception as exc:
print("candidate_commit_error:", type(exc).__name__, str(exc))
PYRepository: hyperpolymath/wordpress-tools Length of output: 699 🌐 Web query:
💡 Result: In GitHub Actions, pinning to a full-length commit SHA is the only way to ensure an action reference is immutable [1][2][3]. While tags (e.g., Citations:
Use the immutable commit SHA recorded in The workflow uses the mutable 🤖 Prompt for AI AgentsSource: MCP tools |
||
| with: | ||
| server_address: ${{ secrets.SMTP_HOST }} | ||
| server_port: ${{ secrets.SMTP_PORT }} | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
sed -n '1,90p' .github/workflows/push-email-notify.ymlRepository: hyperpolymath/wordpress-tools
Length of output: 3104
🌐 Web query:
GitHub push event deleted branch head_commit null workflow branches filter documentation💡 Result:
When a branch is deleted on GitHub, the resulting push event payload indicates the deletion with a 'deleted' field set to 'true' [1][2]. In this scenario, the 'head_commit' field in the payload is null, and the 'after' SHA is typically represented by a string of zeros (e.g., '0000000000000000000000000000000000000000') [3][4]. Because GitHub Actions workflows triggered by the 'push' event may inadvertently run when a branch is deleted, users often need to explicitly filter these events [5][3]. Key points regarding GitHub Actions and branch deletions: 1. Workflow Triggers: If you use the 'push' event trigger, your workflow will receive notifications for branch deletions [1][2]. When this happens, the workflow run is typically associated with the repository's default branch rather than the deleted one [6]. 2. Filtering in Workflows: To prevent a workflow from executing during a branch deletion, you can add a conditional check to your job steps using the 'if' property [7]. Example: if: ${{!github.event.deleted }} 3. Explicit 'delete' Event: If your goal is to handle branch deletions specifically, you should use the 'delete' event trigger instead of relying on the 'push' event [1][2]. The 'delete' event provides clear information about the deleted reference via 'github.event.ref' [8][7]. Using the 'branches' filter in your workflow configuration (e.g., 'on: push: branches: [main]') may not effectively prevent the 'push' event from firing for deletions on those branches, as the 'deleted' state is a fundamental attribute of the push event itself [3][7]. Consequently, explicit conditional logic is the most reliable way to manage this behavior [7].
Citations:
Exclude deleted branches explicitly.
When
PUSH_EMAIL_ENABLEDistrue, thenotifyjob readsgithub.event.head_commit.message, but a branch-deletion push payload can sethead_committonull. Add a deletion guard to prevent an incomplete notification:Proposed fix
🤖 Prompt for AI Agents
Source: MCP tools