Problem
treehouse status tells me the state of every pool slot, but not what each slot is actually working on. With several agents running in parallel against the same repo, in-use and dirty are the two states I most need to act on, and they are exactly the two where I cannot tell which work is in the slot without a second command per slot.
Today:
1 dirty /home/me/.treehouse/aide-infrastructure-0473fb/1/aide-infrastructure
2 dirty /home/me/.treehouse/aide-infrastructure-0473fb/2/aide-infrastructure
3 in-use /home/me/.treehouse/aide-infrastructure-0473fb/3/aide-infrastructure
4 available /home/me/.treehouse/aide-infrastructure-0473fb/4/aide-infrastructure
5 in-use /home/me/.treehouse/aide-infrastructure-0473fb/5/aide-infrastructure
To answer "which branch is slot 3 on?" I have to run git -C <path> rev-parse --abbrev-ref HEAD for each slot. The pool already knows the path, so the information is one call away from where the user is already looking.
Proposal
Add the checked-out branch to treehouse status, in both the table and --json.
1 dirty (detached @ e82c16e) .../1/aide-infrastructure
2 dirty (detached @ e82c16e) .../2/aide-infrastructure
3 in-use feature/provision-endpoint-exposure .../3/aide-infrastructure
4 available (detached @ e54ee25) .../4/aide-infrastructure
5 in-use feature/test-harness-tooling-fix .../5/aide-infrastructure
and a corresponding field in the JSON payload, e.g. "branch": "feature/..." alongside the existing status / lease_id / processes.
Notes on the detached case
Pre-warmed and returned slots sit at a detached HEAD, so a branch field is legitimately empty for them. Two things that seem worth getting right:
- Report detached honestly rather than resolving it to something branch-like.
git describe --all --contains HEAD will happily print main~1 for a detached slot, which reads as a branch name and is misleading.
- In JSON, an empty string (or
null) for detached is more useful to consumers than a synthesized value, so scripts can distinguish "on a branch" from "not on a branch" without string-matching.
Workaround in use
For anyone who needs this before it lands:
treehouse status --json | python3 -c '
import sys, json, subprocess
def g(p, *a):
return subprocess.run(["git", "-C", p, *a], capture_output=True, text=True).stdout.strip()
for r in json.load(sys.stdin):
b = g(r["path"], "symbolic-ref", "--short", "-q", "HEAD")
if not b:
b = "(detached @ %s)" % g(r["path"], "rev-parse", "--short", "HEAD")
print("%-3s %-11s %-45s %s" % (r["name"], r["status"], b, r["path"]))'Environment
treehouse v2.1.0, Linux (WSL2).
Happy to send a PR if the shape above looks right to you.
Problem
treehouse statustells me the state of every pool slot, but not what each slot is actually working on. With several agents running in parallel against the same repo,in-useanddirtyare the two states I most need to act on, and they are exactly the two where I cannot tell which work is in the slot without a second command per slot.Today:
To answer "which branch is slot 3 on?" I have to run
git -C <path> rev-parse --abbrev-ref HEADfor each slot. The pool already knows the path, so the information is one call away from where the user is already looking.Proposal
Add the checked-out branch to
treehouse status, in both the table and--json.and a corresponding field in the JSON payload, e.g.
"branch": "feature/..."alongside the existingstatus/lease_id/processes.Notes on the detached case
Pre-warmed and returned slots sit at a detached HEAD, so a
branchfield is legitimately empty for them. Two things that seem worth getting right:git describe --all --contains HEADwill happily printmain~1for a detached slot, which reads as a branch name and is misleading.null) for detached is more useful to consumers than a synthesized value, so scripts can distinguish "on a branch" from "not on a branch" without string-matching.Workaround in use
For anyone who needs this before it lands:
Environment
treehouse v2.1.0, Linux (WSL2).
Happy to send a PR if the shape above looks right to you.