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 |
|---|---|---|
|
|
@@ -3,19 +3,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 | ||
|
There was a problem hiding this comment. 🩺 Stability & Availability | 🔵 Trivial 🔎 Supported by static analysis🏁 Script executed: printf '%s\n' '--- applicable repository conventions ---'
find /tmp/coderabbit-repo-knowledge/hyperpolymath-candy-crash-128f418a -path '*/review*/*.md' -o -path '*/workflows*/*.md' -o -path '*/github*/*.md' | sort
printf '%s\n' '--- knowledge tree ---'
find /tmp/coderabbit-repo-knowledge/hyperpolymath-candy-crash-128f418a -maxdepth 2 -type f -name '*.md' | sort
printf '%s\n' '--- workflow ---'
cat -n .github/workflows/push-email-notify.yml
printf '%s\n' '--- relevant references ---'
rg -n -C 3 'concurr|notification storm|SMTP|push-email-notify|timeout-minutes|smtp-notify' .github README.md 2>/dev/null || trueRepository: hyperpolymath/candy-crash Length of output: 8450 🏁 Script executed: printf '%s\n' '--- repository conventions ---'
cat /tmp/coderabbit-repo-knowledge/hyperpolymath-candy-crash-128f418a/architecture/repo-conventions.md
printf '%s\n' '--- repository guidelines ---'
cat /tmp/coderabbit-repo-knowledge/hyperpolymath-candy-crash-128f418a/architecture/repo-guidelines.md
printf '%s\n' '--- issue labelling ---'
cat /tmp/coderabbit-repo-knowledge/hyperpolymath-candy-crash-128f418a/architecture/issue-labeling.md
printf '%s\n' '--- comparable concurrency declarations ---'
cat -n .github/workflows/language-policy.yml | sed -n '1,20p'
cat -n .github/workflows/codeql.yml | sed -n '1,25p'
cat -n .github/workflows/casket-pages.yml | sed -n '1,25p'Repository: hyperpolymath/candy-crash Length of output: 5760 🌐 Web query:
💡 Result: In GitHub Actions, concurrency and timeout controls serve distinct purposes for managing workflow execution, costs, and resource usage. Concurrency Control The concurrency keyword is used to group workflows or jobs, ensuring that only a defined number of runs execute simultaneously within that group [1][2]. When you define a concurrency group: - Default Behavior: By default, GitHub Actions ensures that only one workflow or job with the specified concurrency key runs at a time [1][3]. If a new run starts within the same group, existing in-progress runs can be canceled if configured to do so, or new runs may be queued [4][2]. - Queueing: You can control how pending runs are handled using the optional queue property [1][2]. The default value, single, allows at most one pending run, where a new run cancels any existing pending one [1][2]. Alternatively, setting queue to max allows up to 100 runs to wait in the queue before additional runs are rejected [1][2]. - Cancellation: To automatically cancel in-progress runs when a new run is triggered, you can use the cancel-in-progress: true option (often used alongside a concurrency group key) [5][6]. Timeout Control The timeout-minutes keyword allows you to set an explicit limit on how long a job or step can run [5][6]. - Default Timeout: If not specified, GitHub Actions jobs have a default timeout of 360 minutes (6 hours) [7][5][6]. - Best Practices: Setting an explicit timeout-minutes value is recommended to prevent hung processes from consuming excessive runner minutes, especially since canceled jobs may still spend a short period (up to 5 minutes in some scenarios) finishing cleanup before being forcibly terminated [5][6]. Key Differences Concurrency management focuses on the number of simultaneous executions to avoid race conditions or unnecessary duplicate work, while timeout-minutes focuses on capping the duration of individual jobs to manage costs and prevent "zombie" runs [4][5][6]. Using them together—for example, by using concurrency groups with cancel-in-progress and setting reasonable timeout-minutes—is a standard strategy for optimizing GitHub Actions usage [5][6]. For detailed syntax and configuration examples, refer to the official GitHub Actions documentation on controlling concurrency and workflow syntax [1][8][2]. Citations:
Define and enforce the workflow concurrency policy.
🤖 Prompt for AI AgentsSource: Linters/SAST tools |
||
| steps: | ||
| - name: Send push notification email | ||
| uses: hyperpolymath/smtp-notify-action@ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7 # v0.2.0 | ||
|
There was a problem hiding this comment. 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: set -eu
printf '%s\n' '--- workflow reference ---'
sed -n '36,46p' .github/workflows/push-email-notify.yml
resolve_tag() {
repo=$1
tag=$2
ref=$(curl -fsSL "https://api.github.com/repos/${repo}/git/refs/tags/${tag}")
type=$(printf '%s' "$ref" | jq -r '.object.type')
sha=$(printf '%s' "$ref" | jq -r '.object.sha')
if [ "$type" = tag ]; then
sha=$(curl -fsSL "https://api.github.com/repos/${repo}/git/tags/${sha}" | jq -r '.object.sha')
fi
commit=$(curl -fsSL "https://api.github.com/repos/${repo}/commits/${sha}" | jq -r '.sha')
printf '%s -> %s (%s)\n' "$tag" "$commit" "$type"
}
printf '%s\n' '--- resolved tags ---'
resolve_tag hyperpolymath/smtp-notify-action v0.1.0
resolve_tag hyperpolymath/smtp-notify-action v0.2.0
printf '%s\n' '--- pinned SHA existence ---'
curl -fsSL 'https://api.github.com/repos/hyperpolymath/smtp-notify-action/commits/ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7' | jq -r '.sha'
curl -fsSL 'https://api.github.com/repos/hyperpolymath/smtp-notify-action/commits/1b3b752d39a4fe4c0f28f10905e4608789d3e050' | jq -r '.sha'Repository: hyperpolymath/candy-crash Length of output: 673 🌐 Web query:
💡 Result: There is no public GitHub repository or established project named "smtp-notify-action" under the "hyperpolymath" organization. Searches across the hyperpolymath organization and the general web indicate that hyperpolymath repositories typically utilize the third-party GitHub Action dawidd6/action-send-mail to handle SMTP-based email notifications within their CI/CD workflows [1][2][3]. The specific hashes mentioned in your query do not correspond to any known versions of an "smtp-notify-action" and do not appear to be associated with any internal hyperpolymath tooling by that name. It is possible that "smtp-notify-action" is either a private project, a misremembered name for the dawidd6/action-send-mail dependency, or a hypothetical identifier. You may wish to verify the repository name or check if the functionality is provided by the action mentioned above. Citations:
🏁 Script executed: set -u
repo='https://github.com/hyperpolymath/smtp-notify-action.git'
printf '%s\n' '--- tag refs ---'
git ls-remote --tags "$repo" 'v0.1.0' 'v0.2.0' 'v0.1.0^{}' 'v0.2.0^{}' || true
printf '%s\n' '--- pinned action metadata ---'
for sha in \
1b3b752d39a4fe4c0f28f10905e4608789d3e050 \
ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7
do
printf '%s: ' "$sha"
curl -L --fail --silent --show-error \
"https://raw.githubusercontent.com/hyperpolymath/smtp-notify-action/$sha/action.yml" \
| sed -n '1,80p' || true
doneRepository: hyperpolymath/candy-crash Length of output: 6109 Align the action revision with the PR objective. The workflow pins 🤖 Prompt for AI Agents🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: sed -n '1,90p' .github/workflows/push-email-notify.yml
printf '\n--- workflow permission declarations ---\n'
rg -n '^[[:space:]]*permissions:|github\.token|GITHUB_TOKEN|actions:[[:space:]]*read' .github . --glob '!node_modules' --glob '!dist' --glob '!build' | head -200Repository: hyperpolymath/candy-crash Length of output: 4302 🤖 get_repo_knowledge executed:
Length of output: 3080 🌐 Web query:
💡 Result: In GitHub Actions, the GITHUB_TOKEN is an automatically generated, short-lived secret provided for each job, which allows workflows to authenticate with the GitHub API [1][2][3]. The token is available via the Citations:
🏁 Script executed: python3 - <<'PY'
import json, urllib.request
for path in ("action.yml", "action.yaml"):
url = f"https://raw.githubusercontent.com/hyperpolymath/smtp-notify-action/ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7/{path}"
try:
with urllib.request.urlopen(url, timeout=10) as response:
print(f"--- {path} ---")
print(response.read().decode())
except Exception as exc:
print(f"{path}: {exc}")
PYRepository: hyperpolymath/candy-crash Length of output: 458 🏁 Script executed: curl -ksSfL 'https://raw.githubusercontent.com/hyperpolymath/smtp-notify-action/ede1191ef6ff3ac02c4f4d9efdf837ee517e11d7/action.yml' | sed -n '1,160p'Repository: hyperpolymath/candy-crash Length of output: 5656 Remove the unused The workflow-level declaration grants the SMTP composite action read access to repository contents, although its steps only download the pinned binary and send SMTP inputs. Set the workflow permissions to 🤖 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/candy-crash
Length of output: 2608
🏁 Script executed:
Repository: hyperpolymath/candy-crash
Length of output: 2142
🌐 Web query:
GitHub Actions push event branches filter branch deletion deleted head_commit null documentation💡 Result:
When a branch is deleted in a GitHub repository, it triggers a push event [1][2][3]. In this specific type of push event, the payload indicates the deletion by setting the
deletedattribute totrueand thehead_commitproperty tonull[2][4][3]. Because a branch deletion sends a push event, any workflow configured to trigger onpush(or apushwithbranchesfilters that include the deleted branch) may be triggered [1][4][5]. To prevent workflows from running during branch deletions, you can use a conditionalifexpression to check thegithub.event.deletedcontext [1]: jobs: my_job: if: ${{!github.event.deleted }} runs-on: ubuntu-latest steps: - run: echo "This only runs on actual pushes, not deletions." Alternatively, if you need to specifically handle branch deletions, you can use thedeleteevent instead of thepushevent, which is designed specifically for when a branch or tag is removed [2][3][5]: on: delete: branches: - 'feature/*' Using thedeleteevent allows you to target branch removals explicitly, avoiding the unexpected triggers associated with thepushevent's payload behavior [1][2].Citations:
Exclude deleted branch pushes at the job boundary.
branches: ['**']can match the branch ref on a deletionpush; it does not inspectgithub.event.deleted. Thenotifyjob can therefore pass a deletion payload to the SMTP action withgithub.event.head_commitset tonull, producing an emptyHead msg. Add!github.event.deletedto the job condition.🧰 Tools
🪛 zizmor (1.29.0)
[warning] 12-15: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🤖 Prompt for AI Agents