Guides
Send deployment alerts to your phone
Get a BotComm message when your deployment job finishes. This guide adds a notification step to an existing GitHub Actions deployment job, with a link back to the workflow run.
Prepare your bot and secrets
- Create a bot in the web console and save its Client ID and Client secret.
- Open the bot’s chat in BotComm on iOS or the web. Without a target Session ID, messages go to the owner’s chat.
- Enable notifications in the app and your device settings if you want a push alert.
In your GitHub repository’s Actions secrets, add BOTCOMM_CLIENT_ID and BOTCOMM_CLIENT_SECRET. Use a Linux runner with Bash, Python 3, and cURL 7.76 or later for this example. Your deployment job should already run and report failures through its exit status.
Add the notification step
Append this step to the steps list in your existing deployment job, after the actual deployment. Match the surrounding YAML indentation.
- name: Notify BotComm
if: ${{ !cancelled() }}
continue-on-error: true
env:
CLIENT_ID: ${{ secrets.BOTCOMM_CLIENT_ID }}
CLIENT_SECRET: ${{ secrets.BOTCOMM_CLIENT_SECRET }}
DEPLOY_STATUS: ${{ job.status }}
shell: bash
run: |
: "${CLIENT_ID:?Set BOTCOMM_CLIENT_ID}"
: "${CLIENT_SECRET:?Set BOTCOMM_CLIENT_SECRET}"
payload=$(python3 - <<'PY'
import json
import os
run_url = (
f"{os.environ['GITHUB_SERVER_URL']}/"
f"{os.environ['GITHUB_REPOSITORY']}/actions/runs/"
f"{os.environ['GITHUB_RUN_ID']}"
)
print(json.dumps({
"content": (
f"Deployment job: {os.environ['DEPLOY_STATUS']}\n"
f"{os.environ['GITHUB_REPOSITORY']}\n{run_url}"
)
}))
PY
)
curl --fail-with-body --silent --show-error \
--connect-timeout 10 --max-time 30 \
--user "$CLIENT_ID:$CLIENT_SECRET" \
--header 'Content-Type: application/json' \
--data "$payload" \
https://api.botcomm.app/message
The step reports the job status at that point. It runs after success or failure, unless the workflow has been cancelled. continue-on-error keeps a notification failure from changing a successful deployment into a failed job; it does not erase an earlier deployment failure.
The payload is generated with a JSON encoder, so quotes and line breaks are escaped correctly. A successful send returns HTTP 200 with the message as JSON.
Verify the result
Run the deployment workflow and open your bot’s chat. Expect a message containing Deployment job: success or Deployment job: failure, the repository name, and a link to the run.
This reports the workflow result, not an independent health check of your service. If the deployment command backgrounds work or ignores errors, fix that behavior before relying on its status.
Troubleshooting
- Missing credentials or HTTP 401: check the secret names, their environment scope, and whether the workflow is allowed to access them. Secrets are generally unavailable to workflows triggered from forks.
- HTTP 404: open or reconnect to your bot’s chat before running the workflow.
- The notification step is skipped: check whether the workflow was cancelled, the deployment job never started, or a job-level condition prevented it from running.
- HTTP 429: send one message per deployment instead of one per build task. Review the rate limits.
- A cURL timeout: check your chat before retrying; the first request may already have created the message.
See GitHub’s workflow syntax and secrets documentation for conditions and secret availability.