chore(ci): repoint push-email-notify to smtp-notify-action #60
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -1,23 +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 ---'
sed -n '35,47p' .github/workflows/push-email-notify.yml
printf '%s\n' '--- lock entry ---'
rg -n -C 2 'hyperpolymath/smtp-notify-action|ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7' .github/workflows/actions.lock
printf '%s\n' '--- tag resolution ---'
if command -v gh >/dev/null 2>&1; then
gh api repos/hyperpolymath/smtp-notify-action/git/ref/tags/v0.2.0 --jq '.object.type + " " + .object.sha'
tag_obj="$(gh api repos/hyperpolymath/smtp-notify-action/git/ref/tags/v0.2.0 --jq 'select(.object.type == "tag") | .object.sha')"
if [ -n "$tag_obj" ]; then
gh api "repos/hyperpolymath/smtp-notify-action/git/tags/$tag_obj" --jq '.object.type + " " + .object.sha'
fi
gh api repos/hyperpolymath/smtp-notify-action/commits/ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7 --jq '.sha'
else
echo 'gh unavailable'
fiRepository: hyperpolymath/systemet Length of output: 1321 Pin the action by commit SHA. The tag currently resolves to the recorded commit, but GitHub Actions still consumes the mutable Proposed pin- uses: hyperpolymath/smtp-notify-action@v0.2.0 # NOSONAR — pin authority is actions.lock (sha1-ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7)
+ uses: hyperpolymath/smtp-notify-action@ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7 # v0.2.0📝 Committable suggestion
Suggested change
🤖 Prompt for AI Agents🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- workflow ---'
sed -n '1,90p' .github/workflows/push-email-notify.yml
printf '%s\n' '--- lock entry ---'
rg -n -C 3 'hyperpolymath/smtp-notify-action|ede1191' .github/workflows/actions.lockRepository: hyperpolymath/systemet Length of output: 3853 🌐 Web query:
💡 Result: There is no GitHub Action specifically named "smtp-notify-action" published by "hyperpolymath" [1][2]. The "hyperpolymath" account uses a standard dormant push-email notification workflow in its repositories [3][1][2][4][5][6][7], which relies on the widely used third-party action dawidd6/action-send-mail [3][4][5][6][7]. For the dawidd6/action-send-mail action (and similar tools like simonsfoundation/action-send-mail or caelicode/send-email), the standard configuration for STARTTLS and secure connections typically follows this pattern [8][9]: 1. secure: When set to true, this usually indicates the use of implicit TLS (often on port 465). When set to false, it enables STARTTLS (often on port 587) [8][9]. 2. server_port: This should be configured according to your SMTP provider's requirements—typically 587 for STARTTLS/SMTP submission and 465 for implicit TLS (SMTPS) [8][9]. Since "smtp-notify-action" does not exist as a standalone project by this author, you should refer to the documentation for the specific action being used in your workflow file (such as dawidd6/action-send-mail) [3][4][5][6][7]. If you are implementing a custom workflow, ensure that the server_port matches the encryption method required by your email service provider [8][9]. Citations:
🏁 Script executed: #!/bin/bash
set -eu
repo='hyperpolymath/smtp-notify-action'
ref='v0.2.0'
printf '%s\n' '--- repository/ref ---'
curl -fsSL "https://api.github.com/repos/${repo}" | jq -r '{full_name,default_branch,archived}'
curl -fsSL "https://api.github.com/repos/${repo}/git/ref/tags/${ref}" | jq -r '{ref:.ref,object:.object}'
printf '%s\n' '--- action metadata ---'
curl -fsSL "https://raw.githubusercontent.com/${repo}/${ref}/action.yml"
printf '%s\n' '--- implementation file listing ---'
curl -fsSL "https://api.github.com/repos/${repo}/git/trees/${ref}?recursive=1" |
jq -r '.tree[] | select(.type=="blob") | .path' | sed -n '1,120p'Repository: hyperpolymath/systemet Length of output: 6610 Verify the SMTP transport configuration before merging.
🤖 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 | 🟡 Minor | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
Repository: hyperpolymath/systemet
Length of output: 4598
🌐 Web query:
GitHub Actions push event webhook payload deleted head_commit null branches filter documentation💡 Result:
When a branch is deleted in a GitHub repository, the resulting push event payload indicates the deletion by setting the
deletedattribute totrue[1][2][3]. In this scenario, thehead_commitfield is set tonullbecause there is no remaining head commit on the deleted ref [1][2][3]. Key technical details regarding this behavior include: Webhook Payload: Thepushevent payload explicitly includes adeletedboolean field [1][4]. If this istrue, the event represents a branch or tag deletion, and thehead_commitobject will benull[1][2][3]. Branch Filtering Documentation: You can use thebranchesorbranches-ignorefilters in your workflow definition (e.g., inon: push: branches:) to control which pushes trigger your workflow [5][6][7]. However, these filters act on the ref name (the branch) and do not automatically exclude events where the ref was deleted [5][6]. Because a deletion push event still targets a branch name (the one being deleted), a workflow configured to run on that branch may still be triggered by the deletion event unless explicitly handled [2]. Handling Deletions: If you need to avoid running workflows during branch deletions, you can include a step in your workflow that checks the payload'sdeletedattribute: if: ${{!github.event.deleted }} run: echo "This is not a branch deletion." Alternatively, if you only need to perform actions during deletions, you can use thedeletewebhook event, which is specifically designed for branch or tag deletions [1][3][8]. For additional details on the push event payload structure, refer to the official GitHub Webhook events and payloads documentation [3][4].Citations:
Exclude branch-deletion pushes from the notification job.
branches: ['**']permits branch-deletionpushevents. These payloads havehead_commit: null, so the email can contain missing commit data. Add!github.event.deletedto the job condition.Proposed guard
🤖 Prompt for AI Agents