fix(ci): re-enable finishingbot/seambot/rhodibot via gitbot-fleet (Refs #37)#42
Merged
Merged
Conversation
#37) The three bot workflows were disabled (`if: false`, #36) because they cloned phantom repos (`hyperpolymath/finishing-bot|seambot|rhodibot`) that never existed. The bots actually live in `hyperpolymath/gitbot-fleet` under `bots/`. All three now: clone gitbot-fleet at a pinned commit, build the specific bot crate, and invoke the correct binary — then `if: false` is removed. - finishingbot: binary is `finishing-bot` (hyphenated) — the old workflow also had the wrong binary name; `finishing-bot --path … audit`. - seambot: `seambot check` (unchanged invocation; keeps the spec/seams/seam-register.json guard). - rhodibot: `rhodibot check --owner --repo` — needs the new CLI subcommand from gitbot-fleet#150 (rhodibot was webhook-server-only); uses the built-in read-only GITHUB_TOKEN (public repo, no PAT). Pinned ref is the gitbot-fleet#150 branch HEAD (2e0ea3ca67821a91e650f51bf48a6cfd1c7aae1c); to be bumped to the post-merge main SHA once #150 lands. Refs #37. Sub-issues: #39 (seambot), #40 (finishingbot), #41 (rhodibot). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
hyperpolymath
added a commit
that referenced
this pull request
May 17, 2026
…47) ## Problem The three bot workflows were re-enabled against `gitbot-fleet` in #42, but they were **still red on every run** for two reasons that have nothing to do with the bots themselves (verified from run logs `25977596773`/`777`/`771`): 1. **Step ordering.** `Swatinem/rust-cache` ran *before* the `gitbot-fleet` clone, with `workspaces:` pointing at a path that did not exist yet. rust-cache errored (`The cwd: …/bots/<bot> does not exist!`), the cache never worked, and for **seambot** it left `$RUNNER_TEMP/gitbot-fleet` present so the subsequent `git clone` died with `destination path … already exists and is not an empty directory` (**exit 128**). 2. **Exit-code capture under `set -e`.** `bin … > results.txt 2>&1; echo $? > exit-code.txt` runs under `bash -e`. A non-zero bot exit — which is the *intended gating signal* — aborts the step before the exit-code file is written. The non-`continue-on-error` "Display results" step then hard-fails on the missing file, so the job goes red even though the gate logic was supposed to handle it. ## Fix (all three workflows) - Clone `gitbot-fleet` **before** the cache step; `rm -rf` the target dir first for idempotency. - Capture the exit code without aborting, then re-exit with it: ```bash rc=0 "$BIN" … > <bot>-results.txt 2>&1 || rc=$? echo "$rc" > <bot>-exit-code.txt exit "$rc" ``` This preserves the step's `failure` outcome so the `Fail on …findings/violations` gate still fires on real issues, while the job is green only when the bot is genuinely clean. - Hardened the `Display results` `cat` against a missing file. ## Verification CLI invocations checked against `gitbot-fleet` @ pinned ref `2e0ea3ca` (which **is** gitbot-fleet#150's commit, so `rhodibot check` exists): | bot | invocation | clap definition @ ref | |---|---|---| | finishingbot | `finishing-bot --path <ws> audit` | global `--path` (default `.`) + `Audit` subcommand ✓ | | seambot | `seambot check` | global `--path` (default `.`) + `Check` subcommand ✓ | | rhodibot | `rhodibot check --owner … --repo …` | `Check { owner, repo, format }` (added in #150) ✓ | All three YAML files validated with `yaml.safe_load`. Closes #39 Closes #40 Closes #41 Refs #37 (parent — the three sub-issues complete it) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Re-enables the three bot checks disabled in #36. They were permanent
false-red because they cloned phantom repos (
hyperpolymath/finishing-bot,/seambot,/rhodibot) that never existed. The bots actually live inhyperpolymath/gitbot-fleetunderbots/.Each workflow now: clones
gitbot-fleetat a pinned commit (partialclone + checkout SHA), builds the specific bot crate, runs the correct
binary, then the
if: falseguard is removed.finishingbot→ crate binary isfinishing-bot)finishing-bot --path "$GITHUB_WORKSPACE" auditseambot check(keeps thespec/seams/seam-register.jsonguard)rhodibot check --owner --repo, built-in read-onlyGITHUB_TOKEN(public repo, no PAT)Dependency
rhodibot needs the new
rhodibot checksubcommand added inhyperpolymath/gitbot-fleet#150. The pinned ref is currently that
PR's branch HEAD (
2e0ea3ca67821a91e650f51bf48a6cfd1c7aae1c); it willbe bumped to the post-merge
mainSHA once #150 lands. Do not mergethis before that bump.
Tracking
Refs #37. Native sub-issues: #39 (seambot), #40 (finishingbot —binary-name bug), #41 (rhodibot — blocked on gitbot-fleet#150).
Per estate workflow, #37 closes only on explicit joint agreement.
🤖 Generated with Claude Code