SourceTree Custom Action alerts: choosing a trigger boundary without notification noise
0 reputation · 22 Sept 2020, 07:40 UTC
0 reputation · 22 Sept 2020, 07:40 UTC
I want low-noise alerts from SourceTree on desktop: a single OS notification only when something high-value happens, such as a failed pull or a commit landing on a protected branch, with everything else going to a local log file.
My understanding is that SourceTree Custom Actions are user-invoked menu items rather than an always-on event system, so there is no documented hook that fires automatically after every fetch or commit. I can work around that with a wrapper script or a client-side Git hook that filters conditions and emits one notification, but I am unsure where the correct boundary is. OS-level settings (macOS Notification Center or Windows Focus) can silence banners while preserving the log, so the filtering logic itself is the open problem.
The alert payload should stay minimal: repository name, branch, operation, exit status, timestamp. No tokens, remote URLs with credentials, or patch text. I also know client-side hooks can be bypassed, so protected-branch enforcement stays on the server regardless.
35775 reputation · 22 Sept 2020, 18:52 UTC
**1. What does a SourceTree Custom Action receive?**
%repo% – absolute path to the repository root
%branch% – name of the current branch
%remote% – name of the remote that was used (e.g. origin)
%operation% – the Git operation that the action is attached to (e.g. commit, pull, push)
/bin/sh on macOS/Linux, cmd.exe or powershell.exe on Windows) with the repository root as the current working directory.GIT_DIR unless you set them manually.**2. Automatic triggers – Git hooks vs. custom actions**
post-commit – after a commit is created
post-merge – after a merge (which is what a pull does when it merges) – this can be used to detect a successful or failed pull
pre-push – before a push is sent to the remote
post-pull hook in Git; the pull operation is a combination of fetch and merge, so post-merge is the closest hook for detecting the outcome of a pull.--no-verify, but they are the most reliable way to cover all local operations.**3. Threshold for notifications**
main, release/*, or any branch that matches a user‑defined regex.
~/.sourcetree/alerts.log) with a minimal payload: repository name, branch, operation, exit status, timestamp.
#!/usr/bin/env bash
REPO=$1
BRANCH=$2
OP=$3
EXIT=$4
TIMESTAMP=$(date +%s)
# Decide whether to notify
if [[ $EXIT -ne 0 || $BRANCH =~ ^release/ ]]; then
# macOS notification
osascript -e "display notification '[$REPO] $OP failed on $BRANCH' with title 'SourceTree Alert'"
else
echo "$TIMESTAMP $REPO $BRANCH $OP $EXIT" >> ~/.sourcetree/alerts.log
fi
**4. Practical checklist**
.git/hooks/post-commit, .git/hooks/post-merge, .git/hooks/pre-push).**5. Uncertainty and verification**
Could you confirm which SourceTree version you’re using (e.g. 3.5.x, 3.6.x, or a newer 4.x release)? The placeholder set and hook support can vary slightly between releases, and the answer above assumes a recent 3.x or later build.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 22 Sept 2020, 08:57 UTC
Beyond the documented placeholders (%repo%, %branch%, etc.), SourceTree also injects a small set of environment variables when launching a Custom Action. On current macOS/Windows builds (tested on 3.4.x and 4.x) you can rely on ST_REPO_PATH (absolute repository root) and ST_FILE_PATH (selected file or folder, empty when the action is repository-scoped). These are available even when the placeholder set is limited by version, so a filter script can read $ST_REPO_PATH / %ST_REPO_PATH% directly instead of depending on %repo% expansion.
Quick verification: create a throwaway action that runs env | grep ^ST_ > /tmp/st_env.txt (macOS/Linux) or set ST_ > %TEMP%\st_env.txt (Windows), invoke it from the UI, and inspect the file. This confirms the exact variable names on your build before you bake them into a production notifier.