chore(ci): repoint push-email-notify to smtp-notify-action#113
Uh oh!
There was an error while loading. Please reload this page.
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) | ||
There was a problem hiding this comment. 🩺 Stability & Availability | 🔵 Trivial 🔎 Supported by static analysis🏁 Script executed: #!/bin/bashset -eu
printf'%s\n''--- workflow ---'
cat -n .github/workflows/push-email-notify.yml | sed -n '35,48p'printf'%s\n''--- action pins and SMTP settings ---'
rg -n -C 3 'smtp-notify-action|SMTP_(HOST|PORT|USER|PASSWORD)|secure' .github
printf'%s\n''--- repository files related to the lock ---'
git ls-files '.github/*'| rg 'actions\.lock|smtp|email|notify'||trueRepository: hyperpolymath/ubicity Length of output: 5155 🌐 Web query:
💡 Result: There is no public GitHub action named smtp-notify-action authored by the organization or user hyperpolymath. Extensive searches of the hyperpolymath GitHub organization repositories reveal that they utilize dawidd6/action-send-mail to handle SMTP-based email notifications in their automated workflows [1][2][3][4][5]. In the workflows used by hyperpolymath, the email notification step is configured with the following standard parameters [1][2][3][4][5]: - server_address: ${{ secrets.SMTP_HOST }} - server_port: ${{ secrets.SMTP_PORT }} - secure: true - username: ${{ secrets.SMTP_USER }} - password: ${{ secrets.SMTP_PASS }} When setting up SMTP clients (including generic GitHub actions, home automation, or custom implementations), secure=true typically manages connection security [6][7]. Depending on the specific server implementation: 1. Implicit TLS: The connection is encrypted from the start (often port 465) [8]. 2. STARTTLS: An unencrypted connection (often port 587) is upgraded to TLS before authentication (AUTH PLAIN or similar) occurs [8][9][10]. If you are encountering issues with AUTH PLAIN, ensure that your configuration correctly initiates TLS (either implicitly or via STARTTLS) before attempting authentication, as most secure SMTP servers will reject credentials sent over an unencrypted connection [9][10]. Citations:
🏁 Script executed: #!/bin/bashset -u
url='https://raw.githubusercontent.com/hyperpolymath/smtp-notify-action/v0.2.0/action.yml'printf'%s\n''--- action.yml ---'
curl -fsSL "$url"||trueprintf'%s\n''--- repository/ref metadata ---'
curl -sS -D- -o /tmp/smtp-notify-ref.json \
'https://api.github.com/repos/hyperpolymath/smtp-notify-action/git/ref/tags/v0.2.0'||true
cat /tmp/smtp-notify-ref.json 2>/dev/null ||trueprintf'%s\n''--- pinned commit lookup ---'
curl -sS \
'https://api.github.com/repos/hyperpolymath/smtp-notify-action/commits/ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7'||trueRepository: hyperpolymath/ubicity Length of output: 7374 Verify the SMTP provider before merging. If the provider expects STARTTLS on port 587, this step will fail because 🤖 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 references ---'
rg -n -C 2 'smtp-notify-action|ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7|v0\.2\.0' .github actions.lock 2>/dev/null ||trueRepository: hyperpolymath/ubicity Length of output: 2573 🤖 get_repo_knowledge executed:
Length of output: 522 🏁 Script executed: set -eu
repo='hyperpolymath/smtp-notify-action'
tag='v0.2.0'
sha='ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7'printf'%s\n''--- tag ref ---'
curl -fsSL "https://api.github.com/repos/${repo}/git/ref/tags/${tag}"|
jq -c '{ref, object: {type: .object.type, sha: .object.sha}}'printf'%s\n''--- dereferenced tag commit ---'
curl -fsSL "https://api.github.com/repos/${repo}/commits/${tag}"|
jq -c '{sha, message: (.commit.message | split("\n")[0])}'printf'%s\n''--- proposed SHA commit ---'
curl -fsSL "https://api.github.com/repos/${repo}/commits/${sha}"|
jq -c '{sha, message: (.commit.message | split("\n")[0])}'Repository: hyperpolymath/ubicity Length of output: 521 🏁 Script executed: printf'%s\n''--- actions.lock references and tooling ---'
rg -n -C 3 'actions\.lock|lock authority|pin authority|commit:|ref:' .github .2>/dev/null |
rg -v 'node_modules|dist|build'|
head -n 240Repository: hyperpolymath/ubicity Length of output: 10523 🌐 Web query:
💡 Result: To secure your GitHub Actions workflows, official documentation recommends pinning actions to a full-length (40-character) commit SHA [1][2]. This is currently the only way to treat an action reference as an immutable release [1][3], mitigating the risk of malicious actors modifying an action's repository (e.g., adding a backdoor) by moving or deleting tags [1][2]. Key practices for secure, immutable action references include: 1. Use Full-Length SHAs: You must use the full 40-character commit SHA, not an abbreviated value [2]. An abbreviated SHA does not provide the same security guarantee and is not supported for immutable pinning [2]. 2. Maintain Update Capabilities: To continue receiving security updates and version improvements, it is a recommended industry practice to include the human-readable version as a trailing comment in the workflow file (e.g., uses: actions/checkout@a824008 # v4.2.0) [2][4][5]. Modern package managers like Dependabot can parse this comment to propose automated pull requests for new versions while maintaining the immutable SHA reference [4][5]. 3. Enforce via Policies: Administrators can proactively require SHA pinning at the repository, organization, or enterprise level through GitHub Actions allowed actions policies [6][7]. When this policy is enabled, workflows that attempt to use actions pinned to tags or branches instead of a full commit SHA will fail [6]. 4. Verify Source: Always ensure the SHA originates from the legitimate action's repository rather than a fork [1][8]. By combining immutable SHA pinning with dependency management tools like Dependabot, you can achieve both supply chain security and operational efficiency [5]. Citations:
Pin the action reference to the reviewed commit. The workflow still executes the mutable 🤖 Prompt for AI AgentsSource: MCP tools | ||
| with: | ||
| server_address: ${{ secrets.SMTP_HOST }} | ||
| server_port: ${{ secrets.SMTP_PORT }} | ||
Uh oh!
There was an error while loading. Please reload this page.
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/ubicity
Length of output: 4526
🌐 Web query:
GitHub Actions push event branch filters branch deletion github.event.deleted workflow💡 Result:
In GitHub Actions, the push event is triggered by a variety of activities, including branch creation and branch deletion [1]. When a branch is deleted, the push event is fired, and the GITHUB_SHA in the resulting workflow run reverts to the default branch of the repository [2][3][4]. Because the push event triggers on branch deletion, workflows that include branch filters (e.g., on: push: branches: ['main']) may be unexpectedly triggered when other branches are deleted if they are not correctly scoped or if the default branch is included in the filter [2][5][3]. Key points regarding this behavior: 1. Push Event and Deletion: Deleting a branch is a push event activity [1]. Consequently, if your workflow is configured to run on pushes to your default branch, it may execute when any branch is deleted because the context of the push event during a deletion effectively points back to the default branch [2][3][4]. 2. Branch Filters: If you use the branches filter to restrict a workflow, the workflow will only run if the event matches the specified branch patterns [2][6][7]. If your filter includes the default branch, the workflow will likely trigger upon the deletion of any branch in the repository [5]. 3. Handling Deletions: To specifically handle or ignore branch deletions, you can use the delete event, which is separate from the push event [1][8]. The delete event triggers a workflow only when a branch or tag is deleted and is specifically designed for this purpose [3][7][8]. Note that for the delete event to work, the workflow file must exist on the default branch of the repository [8]. If you want to distinguish between a regular code push and a branch deletion, you can use the github.event context within your workflow jobs. For example, you can check for the absence of deletion-related flags or explicitly handle the delete event in a separate job within the same workflow [1]. Alternatively, if you wish to prevent a workflow from running on branch deletion, you can add conditional logic (if statements) to your jobs to check the event context [1]. Top results: [2] https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows [5] https://github.com/UltCombo/action-filter-deleted-branches [1] https://stackoverflow.com/questions/78692595/react-to-specific-branch-getting-deleted-on-github [3] https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows [8] https://stackoverflow.com/questions/76852071/github-actions-delete-event-does-not-trigger-my-workflow [4] https://github.com/github/docs/blob/main/content/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows.md
Citations:
🌐 Web query:
site:docs.github.com actions workflow push event deleted true head_commit null branches filter branch deletion💡 Result:
When a Git branch is deleted in a GitHub repository, it triggers a push event payload where the deleted property is set to true and the head_commit property is null [1][2]. Because this deletion is processed as a push event, workflows configured to trigger on push may be initiated if the branch being deleted matches any specified branches or branches-ignore filters [3][4]. When this occurs, the workflow runner environment uses the default branch of the repository for the commit SHA (GITHUB_SHA) and Git ref (GITHUB_REF) instead of the deleted branch, as the specific ref no longer exists [3][4]. If you wish to handle branch deletions specifically without triggering unwanted push workflows, it is recommended to use the delete event instead [1][2]. The delete event is purpose-built for branch and tag deletions and avoids the ambiguity of the push event's payload for these actions [4][5].
Citations:
Exclude deleted branch events explicitly.
When a branch is deleted, the
pushevent setsgithub.event.deletedtotrueandgithub.event.head_committonull. Since the job checks onlyvars.PUSH_EMAIL_ENABLED, it can send a misleading notification. Add!github.event.deletedto the job condition.🤖 Prompt for AI Agents
Source: MCP tools