-
-
Notifications
You must be signed in to change notification settings - Fork 0
chore(ci): repoint push-email-notify to smtp-notify-action #105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
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. | ||
| # 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: {} | ||
| 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: dawidd6/action-send-mail@v3.12.0 | ||
| uses: hyperpolymath/smtp-notify-action@v0.2.0 # NOSONAR — pin authority is actions.lock (sha1-ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7) | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- workflow ---'
sed -n '1,100p' .github/workflows/push-email-notify.yml
printf '%s\n' '--- action references and SMTP configuration ---'
rg -n -C 3 'smtp-notify-action|SMTP_(HOST|PORT|USER|PASSWORD|FROM|TO)|PUSH_EMAIL_ENABLED|STARTTLS|AUTH PLAIN' .github README.md docs 2>/dev/null || true
printf '%s\n' '--- repository files related to the action lock ---'
git ls-files | rg '(^|/)(actions\.lock|.*smtp.*notify.*|.*email.*notify.*)$' || true
printf '%s\n' '--- upstream v0.2.0 migration contract ---'
curl -fsSL https://raw.githubusercontent.com/hyperpolymath/smtp-notify-action/v0.2.0/MIGRATION.adoc
printf '%s\n' '--- upstream v0.2.0 action implementation ---'
curl -fsSL https://raw.githubusercontent.com/hyperpolymath/smtp-notify-action/v0.2.0/action.ymlRepository: hyperpolymath/verisimdb-data Length of output: 22864 Use a compatible SMTP endpoint before enabling this workflow. The workflow sets 🤖 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/verisimdb-data
Length of output: 4042
🌐 Web query:
GitHub Actions push event branches filter branch deletion deleted true head_commit null workflow💡 Result:
When a branch is deleted on GitHub, the
pushwebhook event is triggered [1][2]. In this specific payload, thedeletedfield is set totrue, and thehead_commitobject isnull[3]. Because apushevent is fired during a branch deletion, workflows configured withon: pushwill trigger by default [3]. If your workflow logic attempts to access properties withinhead_commit(such asgithub.event.head_commit.message), the workflow may fail or error becausehead_commitisnull[3][4]. To manage or ignore these events, you can use the following strategies: 1. Ignore branch deletion in apushworkflow: You can add a condition to your job to skip execution when the push represents a deletion [3]: jobs: my_job: if: ${{!github.event.deleted }} runs-on: ubuntu-latest steps: - run: echo "This only runs if the branch was not deleted." 2. Use thedeleteevent instead: If your goal is to handle branch deletions specifically, thedeleteevent is the appropriate trigger [5][6]. Note that when using thedeleteevent,GITHUB_REFpoints to the default branch, not the branch that was deleted [6][7]. To identify the deleted branch, you should access the payload via the context [7]: on: delete jobs: delete_handler: if: github.event.ref_type == 'branch' runs-on: ubuntu-latest steps: - run: echo "The deleted branch was: ${{ github.event.ref }}" Summary of payload behavior during deletion: -deleted:true[1][3] -head_commit:null[3] -after:0000000000000000000000000000000000000000[3]Citations:
🌐 Web query:
site:docs.github.com actions workflow syntax on.push.branches branch deletion filter💡 Result:
In GitHub Actions, the
pushevent includes branch deletions [1]. When a branch is deleted, thepushevent is triggered, and your workflow filters (branchesorbranches-ignore) will be evaluated against that event [2][3][4]. There is no specificon.push.branchessyntax to exclusively filter for or against branch deletions. However, you can manage this behavior using the following approaches: 1. How it works: When a branch is deleted, thepushevent payload indicates the deletion [1]. The workflow filters evaluate the branch name associated with the push event [2]. If yourbranchesfilter matches the name of the branch that was deleted, the workflow will trigger [3]. 2. Detecting deletions within the workflow: Since there is no native syntax to filter "only deletions" or "exclude deletions" within theon.pushconfiguration, you must handle this logic inside your workflow steps [1]. You can check thedeletedproperty of the push event or evaluate theGITHUB_REFenvironment variable [3][1]. Specifically, you can use anifcondition on a job or step: - To run a job only on deletion: jobs: example: if: github.event.deleted == true runs-on: ubuntu-latest steps: - run: echo "Branch was deleted" - To run a job only on push (excluding deletion): jobs: example: if: github.event.deleted == false runs-on: ubuntu-latest steps: - run: echo "Branch was pushed" If you require a workflow to trigger specifically and only when a branch is deleted (and not on normal code pushes), consider using thedeleteevent instead of thepushevent [1]. Thedeleteevent is explicitly designed to trigger when a Git branch or tag is deleted [1]. on: delete: # Optional: Filter by specific branches if needed branches: - 'main' Using thedeleteevent separates your deletion-handling logic from standard push logic, preventing your build or deployment workflows from inadvertently running when a branch is removed [1].Citations:
Exclude branch-deletion events from email notifications.
When
PUSH_EMAIL_ENABLEDis'true', thenotifyjob runs for matching branch-deletionpushevents. These events can setgithub.event.head_committonull, so the email can contain missing commit details. Addgithub.event.deleted != trueto the job-level condition.🤖 Prompt for AI Agents