chore(ci): repoint push-email-notify to smtp-notify-action #88
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,47p'
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/refs/tags/v0.2.0
else
curl -fsSL https://api.github.com/repos/hyperpolymath/smtp-notify-action/git/refs/tags/v0.2.0
fiRepository: hyperpolymath/heterogenous-mobile-computing Length of output: 1672 🏁 Script executed: #!/bin/bash
set -eu
api() {
if command -v gh >/dev/null 2>&1; then
gh api "$1"
else
curl -fsSL "https://api.github.com/$1"
fi
}
printf '%s\n' '--- annotated tag target ---'
api repos/hyperpolymath/smtp-notify-action/git/tags/e5e4b8d9978e34b40712361a825855e7be466160
printf '%s\n' '--- locked SHA resolution ---'
api repos/hyperpolymath/smtp-notify-action/commits/ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7
printf '%s\n' '--- tag target commit resolution ---'
api repos/hyperpolymath/smtp-notify-action/commits/$(api repos/hyperpolymath/smtp-notify-action/git/tags/e5e4b8d9978e34b40712361a825855e7be466160 | jq -r '.object.sha') | jq -r '.sha'Repository: hyperpolymath/heterogenous-mobile-computing Length of output: 12404 🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- lock policy and enforcement references ---'
rg -n -C 3 'actions\.lock|pin authority|NOSONAR|lock(action|file)?|immutable|commit SHA' .github README.md . 2>/dev/null | head -240Repository: hyperpolymath/heterogenous-mobile-computing Length of output: 16925 🌐 Web query:
💡 Result: The gh-actions-lock CLI and the associated actions.lock file (currently using schema v0.0.2) represent an effort to manage GitHub Actions dependencies by pinning them to specific, verified commit SHAs [1][2]. Key Technical Details: - Purpose: The tool generates and maintains a.github/workflows/actions.lock file, which serves as a record of resolved action dependencies, mapping them to immutable commit SHAs [2]. - Schema v0.0.2: This is the current schema version [1][3]. The lockfile format organizes dependencies by Citations:
Pin the action to the locked commit SHA. GitHub Actions does not read 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 |
||||||
| 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:
sed -n '1,90p' .github/workflows/push-email-notify.ymlRepository: hyperpolymath/heterogenous-mobile-computing
Length of output: 3118
🌐 Web query:
GitHub Actions push event branches filter branch deletion branches '**' deleted event💡 Result:
The push event in GitHub Actions is technically triggered when a branch is deleted [1]. However, because the branch no longer exists at the time the workflow runs, GitHub typically reverts to the repository's default branch [2][3]. This can lead to unexpected workflow executions if you have configured broad filters like
branches: [''][2][4]. Key considerations regarding this behavior include: Branch Deletion and Pushes: When a branch is deleted, the push event is registered by GitHub [1]. Since the branch is gone, the workflow environment resolves to the default branch [2][3]. This means that workflows restricted to certain branches via thebranchesfilter may still trigger or behave inconsistently during a deletion event [1]. Filtering Limitations: You cannot usebranchesorbranches-ignorefilters to specifically exclude or include branch deletion events for the push trigger [4][5]. These filters are designed to control which branch pushes initiate a workflow run [4]. Because the delete event happens independently of the push event, if you need to handle or ignore deletions specifically, you should use thedeleteevent type [6]. Handling Deletion Events: If you need to perform logic specifically when a branch is deleted, use theon: deletetrigger [6][7]. Inside the workflow, you can filter for branch deletions by checking thegithub.event.ref_typecontext [6]: on: delete: jobs: cleanup: if: github.event.ref_type == 'branch' runs-on: ubuntu-latest steps: - name: Handle branch deletion run: echo "Branch ${{ github.event.ref }} was deleted." If you need to ensure a workflow does not run during a branch deletion on a push event, you may need to add conditional logic (theifexpression) to your jobs to check for the deletion state, as standardbranchesfilters do not natively provide a "not-deleted" toggle [1].Citations:
🌐 Web query:
site:docs.github.com actions push event deleted branches filter "deleted" "branches"💡 Result:
In GitHub Actions, the push event does not have a native filter to specifically include or exclude deleted branches [1][2]. When a branch is deleted, GitHub triggers a push event where the SHA reverts to the default branch of the repository, but the event itself remains a push event [1][3]. If you need to detect or react to a branch deletion in a workflow, you should use the delete event instead of the push event [2][3]. Key details: - Push Event: Triggered when a branch is deleted, but it is treated as a standard push event [1][2]. There is no specific activity type or filter within the push event to distinguish deletions from normal code pushes [1][4]. - Delete Event: This event is specifically designed to run when a Git reference (branch or tag) is deleted [3]. You can configure your workflow to respond to this event by using: on: delete: If you are using the push event and need to identify if a branch deletion occurred within your job steps (rather than triggering the workflow itself), you can inspect the payload or the Git state, though this is less direct than using the delete event [2]. The push event payload includes a boolean field named deleted, which indicates whether the push resulted in the deletion of the reference [2]. You can access this in your workflow if needed for conditional logic within a step.
Citations:
Exclude deleted branches from this notification job.
branches: ['**']does not exclude branch-deletion push events. Since the job checks onlyPUSH_EMAIL_ENABLED, it can send a notification with a missinggithub.event.head_commit.message. Add&& !github.event.deletedto the job condition.🤖 Prompt for AI Agents
Source: MCP tools