chore(ci): repoint push-email-notify to smtp-notify-action #121
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,24 +1,46 @@ | ||
| # SPDX-License-Identifier: MPL-2.0 | ||
| # This workflow is managed by gh actions-lock. | ||
| # Dormant push-email notification. ARMED by setting the repo variable | ||
| # 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. 🔒 Security & Privacy | 🟠 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 | sed -n '35,49p'
printf '%s\n' '--- lock entry ---'
rg -n -C 2 'smtp-notify-action|ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7|v0\.2\.0' .github/workflows/actions.lockRepository: hyperpolymath/scripts Length of output: 1376 🏁 Script executed: #!/bin/bash
set -eu
api='https://api.github.com/repos/hyperpolymath/smtp-notify-action'
tag_json="$(curl -fsSL -H 'Accept: application/vnd.github+json' "$api/git/ref/tags/v0.2.0")"
printf '%s\n' '--- tag reference ---'
printf '%s\n' "$tag_json" | jq '{ref: .ref, type: .object.type, sha: .object.sha}'
tag_type="$(printf '%s' "$tag_json" | jq -r '.object.type')"
tag_sha="$(printf '%s' "$tag_json" | jq -r '.object.sha')"
if [ "$tag_type" = tag ]; then
resolved_sha="$(curl -fsSL -H 'Accept: application/vnd.github+json' "$api/git/tags/$tag_sha" | jq -r '.object.sha')"
else
resolved_sha="$tag_sha"
fi
printf '%s\n' "resolved_commit=$resolved_sha"
printf '%s\n' '--- pinned commit lookup ---'
curl -fsSL -H 'Accept: application/vnd.github+json' "$api/commits/ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7" |
jq '{sha: .sha, message: .commit.message}'Repository: hyperpolymath/scripts Length of output: 1909 Pin the action by commit SHA in
🤖 Prompt for AI Agents🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/sh
set -eu
printf '%s\n' '--- workflow ---'
sed -n '35,50p' .github/workflows/push-email-notify.yml
printf '%s\n' '--- actions.lock entry ---'
rg -n -C 2 'hyperpolymath/smtp-notify-action|smtp-notify-action' .github/workflows/actions.lock
printf '%s\n' '--- repository references to SMTP inputs ---'
rg -n -C 2 'SMTP_(HOST|PORT|USER|USERNAME|PASSWORD|FROM|TO)|secure:|smtp-notify-action' .github/workflows .github 2>/dev/null || trueRepository: hyperpolymath/scripts Length of output: 7134 🌐 Web query:
💡 Result: There is no public GitHub action named "smtp-notify-action" published by the user or organization "hyperpolymath". Searches for this specific name return no direct matches for an action or repository [1][2][3][4]. Repositories owned by "hyperpolymath" do, however, utilize the popular "dawidd6/action-send-mail" GitHub action for push-email notifications in their CI/CD workflows [1][2][3][4]. These workflows commonly configure the action with the following parameters: server_address: ${{ secrets.SMTP_HOST }} server_port: ${{ secrets.SMTP_PORT }} secure: true username: ${{ secrets.SMTP_USER }} password: ${{ secrets.SMTP_PASS }} In the context of SMTP, "secure: true" when used with this action typically implies that the connection should use TLS. In many SMTP configurations: 1. STARTTLS: If connecting to port 587 (the standard submission port), STARTTLS is commonly used to upgrade an initially unencrypted connection to a secure one before sending authentication credentials like AUTH PLAIN [5][6][7][8]. 2. Implicit TLS: If connecting to port 465, the connection is often encrypted from the start [9][7][10]. When using AUTH PLAIN, it is a security best practice to ensure the SMTP connection is already encrypted (via STARTTLS or implicit TLS) before sending credentials to prevent them from being transmitted in the clear [5][6][8]. Citations:
🏁 Script executed: #!/bin/sh
set -eu
url='https://raw.githubusercontent.com/hyperpolymath/smtp-notify-action/v0.2.0/action.yml'
printf '%s\n' '--- action.yml ---'
curl -fsSL "$url" | sed -n '1,160p'
printf '%s\n' '--- repository/ref status ---'
curl -sS -o /tmp/smtp-action-ref.json -w 'HTTP %{http_code}\n' \
'https://api.github.com/repos/hyperpolymath/smtp-notify-action/git/ref/tags/v0.2.0'
sed -n '1,80p' /tmp/smtp-action-ref.jsonRepository: hyperpolymath/scripts Length of output: 6108 🏁 Script executed: #!/bin/sh
set -eu
curl -fsSL \
'https://api.github.com/repos/hyperpolymath/smtp-notify-action/git/trees/v0.2.0?recursive=1' |
jq -r '.tree[] | select(.type == "blob") | .path' |
grep -E '(^|/)(README|readme|src|source|.*\.(c|h|zig|idr|adoc))$' |
head -80Repository: hyperpolymath/scripts Length of output: 405 🏁 Script executed: #!/bin/sh
set -eu
for file in src/smtp.zig src/main.zig README.adoc MIGRATION.adoc; do
printf '%s\n' "--- $file ---"
curl -fsSL "https://raw.githubusercontent.com/hyperpolymath/smtp-notify-action/v0.2.0/$file" |
grep -n -E -C 3 'AUTH|auth|STARTTLS|starttls|implicit|secure|SMTP_SECURE|SMTP_PORT' |
head -160
doneRepository: hyperpolymath/scripts Length of output: 17368 Confirm the SMTP server contract before enabling this workflow.
🤖 Prompt for AI Agents |
||
| 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:
Repository: hyperpolymath/scripts
Length of output: 6987
🌐 Web query:
GitHub Actions push event branches filter branch deletion deleted true head_commit null workflow github.event.deleted documentation💡 Result:
In GitHub Actions, the push event is triggered when a branch is deleted [1][2]. In the associated webhook payload, the deleted field is set to true, and the head_commit object is null [1][3]. Key details regarding this behavior: 1. Handling Deletions: Because the push event triggers on branch deletions, workflows configured with on: push may run unintentionally when a branch is deleted [4][5]. The head_commit being null is expected behavior in the payload when a deletion occurs [1][2]. 2. Recommended Approach: Instead of relying on the push event to handle deletions, the standard practice is to use the dedicated delete event [6][7][8]. The delete event is specifically designed to trigger when a Git reference (branch or tag) is removed [6][8]. 3. Payload Access: Within a delete event workflow, you can access the name of the deleted branch using the github.event.ref context [9][5]. Note that unlike the push event, where GITHUB_REF provides the ref currently checked out, the delete event's github.event.ref contains the simple name of the deleted reference [9]. 4. Conditional Filtering: If you must use the push event and need to filter out deletions, you can use a conditional step or job constraint to check the event payload [5]. For example: if: ${{!github.event.deleted }} This condition prevents the job from running when the push event was triggered by a branch deletion [5]. Alternatively, third-party actions exist to filter out such events, though using native event types or conditional logic is generally preferred [4][10].
Citations:
Exclude branch-deletion pushes.
branches: ['**']also permits branch-deletion push events. Add!github.event.deletedto thenotifyjob condition to prevent misleading emails.🤖 Prompt for AI Agents