Bitbucket Pipeline Watch — wake-on-completion, diagnosis-in-hand
§0 — BEING > Rules
Serves the operator's intent: stop burning context-cache on ScheduleWakeup polling and stop the 3-call failure dance (get_steps → auto_diagnose → fetch log). If it obstructs delivering value NOW, skip it and proceed. ⛔ The API token is never echoed — secret-safety is non-negotiable.
The problem it solves
An agent that wants to "act when the pipeline finishes" has two bad options:
- Fixed-interval
ScheduleWakeup— wakes every N seconds, pays a context cache-miss each time, and still has to go fetch the failure details. - A true inbound webhook — impossible: a local agent has no public HTTP endpoint, and the harness has no "inbound POST → re-invoke agent" bridge.
The viable equivalent: a backgrounded poll-until-done loop. The harness re-invokes the agent when a backgrounded Bash command exits. So a script that blocks until the build ends — and prints the verdict + (on failure) the diagnosis before exiting — gives event-driven wake-on-completion with the answer already in hand. No public endpoint, no cache-miss spam, no follow-up calls.
When to use
- You triggered/pushed a Bitbucket pipeline and need to act on green/red (merge gate, PDCA iterate, hand-off).
- You are in a
/quiesce/auto-pilot loop monitoring a CI run. - You want the failure logs automatically if it fails, not just a status bit.
When NOT to use: you only need a one-shot current status → call mcp__maos-mcp-hub__atlassian_bitbucket pipeline get/get_steps directly (synchronous, no wait). The build is already done → just read it.
How to use
# Background it — the harness wakes you when it exits (on COMPLETED or timeout):
bin/bb-pipeline-watch.sh --build 1363 --repo vks-jss-sales-api & # run_in_background:true
# or watch the latest build on a branch:
bin/bb-pipeline-watch.sh --latest --branch feature/x --repo vks-jss-sales-api
# one-shot sanity check (no loop):
bin/bb-pipeline-watch.sh --build 1363 --repo vks-jss-sales-api --once
On wake, read the command's output file:
=== BUILD <n> COMPLETED: SUCCESSFUL ===→ act on green.=== BUILD <n> COMPLETED: FAILED ===followed byFAILURE DIAGNOSIS (redacted)→ the failed step(s) + the error-relevant log tail are already there; decide the fix without extra calls.
Contract
- Creds: read from the maos-mcp-hub
.env(BITBUCKET_API_TOKEN, Bearer) in a subshell; override with--env-file/BB_WATCH_ENV_FILE. The token is used only in anAuthorizationheader and never printed. - Redaction: all log output passes through
redact()(masksASIA…/AKIA…keys, long base64 secrets,*_token/*secret*/passwordvalues). Anti-theater: a leaked secret in a "helpful" log is worse than no log. - Exit:
0on a reached verdict OR timeout (clean background completion → harness wake); non-zero only on setup error (missing token / bad args). - Bounds:
--interval(default 45s),--max-polls(default 80 ≈ 60min). Deterministic — no model judgment in the loop.
Anti-patterns
- ❌ Fixed-interval
ScheduleWakeuppolling for a build the harness could wake you on. ❌ Callingget_steps→diagnose→fetch logby hand on every failure (this bakes it in). ❌ Echoing the token or an un-redacted log. ❌ Using it for a one-shot status (use the MCP gateway directly).
Refs
- Pairs with
mcp-tools/maos-mcp-hubatlassian_bitbucketgateway (pipeline get/get_steps/auto_diagnose). - Pattern origin:
vks-jss-sales-apiPR#85 (build 1362 FAILED → needed get_steps+diagnose+log by hand; this skill collapses that into one backgrounded wait). Cross-link[[bitbucket-pipeline-watch]]. - Mechanism: Claude Code re-invokes the agent on backgrounded-
Bashexit (the "wake me when it finishes" equivalent of a webhook).