chore(ci): repoint push-email-notify to smtp-notify-action #151
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -4,20 +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) | ||||||
|
Contributor
There was a problem hiding this comment. 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -u
printf '%s\n' '--- workflow ---'
sed -n '35,50p' .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' '--- tag reference ---'
curl -fsSL 'https://api.github.com/repos/hyperpolymath/smtp-notify-action/git/ref/tags/v0.2.0' |
jq '{ref, object}'
printf '%s\n' '--- pinned commit resolution ---'
curl -fsSL 'https://api.github.com/repos/hyperpolymath/smtp-notify-action/commits/ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7' |
jq '{sha, html_url, message: .commit.message}'Repository: hyperpolymath/universal-chat-extractor Length of output: 3308 🏁 Script executed: #!/bin/bash
set -u
printf '%s\n' '--- annotated tag target ---'
curl -fsSL 'https://api.github.com/repos/hyperpolymath/smtp-notify-action/git/tags/e5e4b8d9978e34b40712361a825855e7be466160' |
jq '{sha: .sha, object}'
printf '%s\n' '--- tag dereference ---'
curl -fsSL 'https://api.github.com/repos/hyperpolymath/smtp-notify-action/commits/v0.2.0' |
jq '{sha, html_url, message: .commit.message}'Repository: hyperpolymath/universal-chat-extractor Length of output: 2166 Pin the action by commit SHA.
Proposed fix- 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 AgentsSource: MCP tools 🩺 Stability & Availability | 🔵 Trivial 🔎 Supported by static analysis🏁 Script executed: #!/bin/sh
set -eu
printf '%s\n' '--- workflow ---'
sed -n '1,100p' .github/workflows/push-email-notify.yml
printf '%s\n' '--- lock entry ---'
rg -n -C 3 'hyperpolymath/smtp-notify-action|ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7' .github/workflows/actions.lock || trueRepository: hyperpolymath/universal-chat-extractor Length of output: 3861 🌐 Web query:
💡 Result: There is no public GitHub Action named "hyperpolymath/smtp-notify-action". Research into the "hyperpolymath" organization's repositories shows they use the third-party "dawidd6/action-send-mail" action for SMTP notifications [1][2][3]. In the context of standard SMTP GitHub Actions (such as "dawidd6/action-send-mail" or similar): 1. SMTP_PORT: This variable is used to specify the port for your SMTP server [1][4]. Common ports include 587 for STARTTLS and 465 for implicit TLS [5][6][4]. 2. STARTTLS: This is typically handled by setting the appropriate connection security parameters [5][6]. Many actions use a boolean "secure" parameter or a specific configuration field to enable TLS/STARTTLS [7][8][9][4]. For example, if "secure" is set to "true" in some actions, it may default to TLS; you should verify the documentation of the specific action you are using to ensure it explicitly supports or requires STARTTLS for port 587 [5][6][4]. 3. Secure Configuration: To ensure a secure connection, verify your SMTP provider's requirements [7]. Using port 465 often implies implicit TLS (SSL/TLS), while port 587 is the standard for STARTTLS upgrades [5][6][4]. Always ensure your "SMTP_HOST", "SMTP_PORT", "SMTP_USER", and "SMTP_PASS" are stored as GitHub Secrets for security [1][7][4]. Citations:
🏁 Script executed: #!/bin/sh
set -u
printf '%s\n' '--- repository metadata ---'
curl -sS -L -w '\nHTTP %{http_code}\n' \
https://api.github.com/repos/hyperpolymath/smtp-notify-action
printf '%s\n' '--- v0.2.0 action manifest ---'
curl -sS -L -w '\nHTTP %{http_code}\n' \
https://raw.githubusercontent.com/hyperpolymath/smtp-notify-action/v0.2.0/action.ymlRepository: hyperpolymath/universal-chat-extractor Length of output: 12684 Use an implicit-TLS port with
🤖 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,220p' .github/workflows/push-email-notify.ymlRepository: hyperpolymath/universal-chat-extractor
Length of output: 3113
🌐 Web query:
GitHub Actions push event branch filters deleted branch event github.event.deleted head_commit null💡 Result:
When a branch is deleted in a GitHub repository, it triggers a push event in GitHub Actions [1]. In this event, the
head_commitproperty in the webhook payload isnullbecause there is no new commit associated with the deletion [2]. To prevent workflows from running when a branch is deleted, you can add a conditional check to your jobs using theifexpression [1]. Becausehead_commitis null during a deletion, checking for it can effectively filter out these events [1]. Example of filtering out deleted branches in a workflow: jobs: build: if: ${{ github.event.head_commit!= null }} runs-on: ubuntu-latest steps: - run: echo "This job will not run if the branch was deleted." Alternatively, you can specifically check thedeletedproperty in the event payload, which is set totruewhen a branch is deleted [1][2]: jobs: build: if: ${{!github.event.deleted }} runs-on: ubuntu-latest steps: - run: echo "This job will not run if the branch was deleted." If you are using branch filters (e.g.,on: push: branches: [main]), the push event triggered by a deletion may still match your filter if the repository's default branch or other branches match your pattern, as the event payload is processed by the workflow engine regardless of thehead_commitvalue [3][4]. Applying theifcondition within your jobs is the recommended approach to explicitly handle or ignore these events [1].Citations:
Exclude branch deletions from the notification job.
branches: ['**']can match branch-deletionpushevents. These events setgithub.event.deletedtotrueand can setgithub.event.head_committonull. The job can therefore send an email without commit details. Add!github.event.deletedto the job condition.🤖 Prompt for AI Agents
Source: MCP tools