Pushover release details

[fentz26]

User description

Enhance Pushover notifications with detailed release information and direct links, while replacing colored emojis with neutral icons.

---

 

---

PR Type

Enhancement

---

Description

• Replace colored emojis with neutral text icons in notification titles

• Add detailed release information to Pushover notifications

• Include clickable URLs with descriptive titles in notifications

• Extend reusable workflow with optional release metadata inputs

---

Diagram Walkthrough

flowchart LR
  A["Pushover Notifications"] -->|"Add release details"| B["Enhanced Messages"]
  A -->|"Replace emojis"| C["Text Icons [OK]/[FAIL]"]
  A -->|"Add URLs"| D["Clickable Links"]
  B --> E["Repository, Commit, Branch Info"]
  D --> F["Release or Workflow URLs"]

Loading

File Walkthrough

Relevant files

Enhancement

build.yml Enhance build workflow Pushover notifications                        .github/workflows/build.yml Replace emoji icons (✅/❌) with text-based icons ([OK]/[FAIL]) in notification titles Add comprehensive release details to success notification message including repository name, commit SHA, branch, and available platforms Add workflow run details to failure notification message including repository, commit, and branch information Include clickable URLs with descriptive titles (url and url_title parameters) for both success and failure notifications +37/-4    pushover-notify.yml Extend reusable workflow with release metadata inputs        .github/workflows/pushover-notify.yml Add three new optional workflow inputs: release_url, commit_sha, and branch for passing release metadata Replace emoji icons with text-based [OK] and [FAIL] icons in notification titles Expand notification messages with detailed release information including repository, commit SHA, branch, and platform availability Add URL and url_title parameters to Pushover API calls with conditional logic for success and failure scenarios Implement fallback URL generation when optional inputs are not provided +46/-4

---

Note

Adds richer Pushover deploy notifications and introduces a reusable notification workflow.

• Enhances success/failure messages in build.yml to include release URL, short commit SHA, branch, and action links (url/url_title), and standardizes titles to [OK]/[FAIL]
• Introduces reusable workflow pushover-notify.yml with inputs for status, version, release_url, workflow_url, commit_sha, and branch, generating the same detailed messages and links

^{Written by Cursor Bugbot for commit e586176. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
_{Learn more about Cursor Agents}

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Shell injection risk Description: Potential shell command injection exists because untrusted workflow_call inputs (e.g., inputs.release_url, inputs.commit_sha, inputs.branch) are interpolated directly into a bash script inside double quotes (e.g., RELEASE_URL="${{ inputs.release_url }}"), so a crafted input containing shell expansions like $(...) or backticks could be executed when the runner parses the script. pushover-notify.yml [44-86] Referred Code COMMIT_SHA="${{ inputs.commit_sha }}" SHORT_SHA="${COMMIT_SHA:0:7}" BRANCH="${{ inputs.branch }}" if [ "${{ inputs.status }}" == "success" ]; then RELEASE_URL="${{ inputs.release_url }}" if [ -z "${RELEASE_URL}" ]; then RELEASE_URL="${{ github.server_url }}/${{ github.repository }}/releases/tag/${VERSION}" fi TITLE="[OK] Deploy Success: ${REPO_NAME}" MESSAGE="Version ${VERSION} deployed successfully to production. Release Details: - Repository: ${REPO_NAME} - Commit: ${SHORT_SHA} - Branch: ${BRANCH} Release: ${RELEASE_URL}" PRIORITY="0" SOUND="pushover" ... (clipped 22 lines)
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
🔴	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Missing input fallbacks: Optional inputs commit_sha and branch are used directly in message construction without fallback defaults, which can lead to empty/incorrect notification details. Referred Code COMMIT_SHA="${{ inputs.commit_sha }}" SHORT_SHA="${COMMIT_SHA:0:7}" BRANCH="${{ inputs.branch }}" if [ "${{ inputs.status }}" == "success" ]; then RELEASE_URL="${{ inputs.release_url }}" if [ -z "${RELEASE_URL}" ]; then RELEASE_URL="${{ github.server_url }}/${{ github.repository }}/releases/tag/${VERSION}" fi TITLE="[OK] Deploy Success: ${REPO_NAME}" MESSAGE="Version ${VERSION} deployed successfully to production. Release Details: - Repository: ${REPO_NAME} - Commit: ${SHORT_SHA} - Branch: ${BRANCH} Release: ${RELEASE_URL}" Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Unvalidated workflow inputs: The workflow uses caller-provided inputs (release_url, branch, commit_sha) directly in notifications without validation/sanitization, which may be acceptable but should be confirmed given the trust boundary of workflow_call. Referred Code release_url: description: 'URL to the release page' required: false type: string commit_sha: description: 'Commit SHA for this release' required: false type: string branch: description: 'Branch name' required: false type: string Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
High-level	Consolidate notification logic into one workflow Refactor build.yml to use the reusable pushover-notify.yml workflow. This change will eliminate duplicated notification logic and centralize it for improved maintainability. Examples: .github/workflows/build.yml [177-208] - name: Send Pushover Notification - Success if: success() run: | VERSION="v${{ needs.build.outputs.version }}" REPO_NAME="${{ github.repository }}" RELEASE_URL="${{ github.server_url }}/${{ github.repository }}/releases/tag/${VERSION}" COMMIT_SHA="${{ github.sha }}" SHORT_SHA="${COMMIT_SHA:0:7}" MESSAGE="Version ${VERSION} deployed successfully to production. ... (clipped 22 lines) .github/workflows/pushover-notify.yml [48-66] if [ "${{ inputs.status }}" == "success" ]; then RELEASE_URL="${{ inputs.release_url }}" if [ -z "${RELEASE_URL}" ]; then RELEASE_URL="${{ github.server_url }}/${{ github.repository }}/releases/tag/${VERSION}" fi TITLE="[OK] Deploy Success: ${REPO_NAME}" MESSAGE="Version ${VERSION} deployed successfully to production. Release Details: ... (clipped 9 lines) Solution Walkthrough: Before: # file: .github/workflows/build.yml - name: Send Pushover Notification - Success run: | # ... logic to build MESSAGE string ... MESSAGE="Version ${VERSION} deployed successfully... Release Details: - Repository: ${REPO_NAME} - Commit: ${SHORT_SHA} ..." curl -s --form-string "token=..." \ --form-string "message=${MESSAGE}" \ ... - name: Send Pushover Notification - Failure run: | # ... logic to build MESSAGE string ... MESSAGE="Version ${VERSION} deployment failed... Details: - Repository: ${REPO_NAME} - Commit: ${SHORT_SHA} ..." curl -s --form-string "token=..." \ --form-string "message=${MESSAGE}" \ ... After: # file: .github/workflows/build.yml - name: Send Pushover Notification - Success if: success() uses: ./.github/workflows/pushover-notify.yml with: status: success version: "v${{ needs.build.outputs.version }}" commit_sha: ${{ github.sha }} branch: ${{ github.ref_name }} secrets: inherit - name: Send Pushover Notification - Failure if: failure() uses: ./.github/workflows/pushover-notify.yml with: status: failure version: "v${{ needs.build.outputs.version }}" commit_sha: ${{ github.sha }} branch: ${{ github.ref_name }} workflow_url: "${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" secrets: inherit Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies significant code duplication between build.yml and pushover-notify.yml, and proposing to use the reusable workflow is a crucial architectural improvement for maintainability.	High
General	Add fallbacks for commit and branch Add fallback default values for the commit_sha and branch inputs to ensure the SHORT_SHA and BRANCH variables are always populated. .github/workflows/pushover-notify.yml [44-46] COMMIT_SHA="${{ inputs.commit_sha }}" + if [ -z "${COMMIT_SHA}" ]; then + COMMIT_SHA="${{ github.sha }}" + fi SHORT_SHA="${COMMIT_SHA:0:7}" BRANCH="${{ inputs.branch }}" + if [ -z "${BRANCH}" ]; then + BRANCH="${{ github.ref_name }}" + fi Apply / Chat Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that commit_sha and branch inputs can be empty and proposes adding fallbacks using github.sha and github.ref_name, which improves the robustness of the reusable workflow.	Medium
More

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

This PR is being reviewed by Cursor Bugbot

Details

You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

Optional inputs lack fallback values in notification message

Low Severity

The new optional inputs commit_sha and branch are used directly in the message template without fallback handling. When callers don't provide these values, the notification displays empty lines like - Commit: and - Branch:. Unlike release_url and workflow_url which have fallbacks using github.server_url, these inputs could similarly fall back to github.sha and github.ref_name to ensure complete notification messages.

Additional Locations (2)

• .github/workflows/pushover-notify.yml#L58-L60
• .github/workflows/pushover-notify.yml#L77-L79