Skip to content

Fix monitor-ci.sh doc/script mismatch: no --commit flag exists - #82

Open
jnasbyupgrade wants to merge 1 commit into
Postgres-Extensions:masterfrom
jnasbyupgrade:fix/monitor-ci-commit-flag-docs
Open

Fix monitor-ci.sh doc/script mismatch: no --commit flag exists#82
jnasbyupgrade wants to merge 1 commit into
Postgres-Extensions:masterfrom
jnasbyupgrade:fix/monitor-ci-commit-flag-docs

Conversation

@jnasbyupgrade

Copy link
Copy Markdown
Contributor

Summary

CLAUDE.md and the /ci skill's own SKILL.md described a --commit SHA
flag for monitor-ci.sh, but the script only ever took positional args
([repos] [branch] [sha_pgxntool_test] [sha_pgxntool]). That flag text
appears to have crept in from ../ai/CLAUDE.md's general gh CLI advice
(gh run list/gh pr checks do take --commit) getting conflated with
this script's own interface.

Concretely, an agent following the doc literally invoked
monitor-ci.sh --commit SHA, which silently misparsed into
REPOS="--commit" (falls through to the "both" default case) with the
SHA landing in BRANCH — the script then polled a nonexistent branch
for ~35 minutes before failing.

Changes

  • CLAUDE.md: describe the actual positional interface instead of a
    --commit flag.
  • .claude/skills/ci/SKILL.md: same fix, plus a separate pre-existing bug
    in the same file — the "most reliable" usage example was missing the
    leading repos arg and had the two SHA args in the wrong order
    relative to the script's real sha_pgxntool_test/sha_pgxntool order.
  • .claude/skills/ci/scripts/monitor-ci.sh: added a guard that fails fast
    with a usage message on a --flag-style invocation, instead of silently
    misparsing and hanging until timeout — a defense against this recurring
    even if some other doc/agent assumes flag syntax again.

Why not add a --commit flag instead

Considered making the script match the (wrong) documented interface
instead of fixing the docs, per this project's usual preference for
fixing the more ergonomic direction. Decided against it:

  • both mode — the default — needs two separate SHAs for two separate
    repos' pushes, so a single --commit SHA flag can't express the
    primary use case at all.
  • The positional form is already load-bearing: the /release skill
    invokes monitor-ci.sh positionally (.claude/skills/release/SKILL.md),
    and SKILL.md's own documented 4-arg form already matches the script
    correctly (only its shorthand one-liner was wrong).

Test plan

  • bash -n syntax check on the modified script
  • Ran monitor-ci.sh --commit abc123def — confirmed it now fails
    fast with exit 64 and a clear usage message (the failure path this
    bug caused)
  • Ran monitor-ci.sh pgxntool-test <nonexistent-branch> (normal
    positional form) — confirmed it proceeds past the new guard and
    enters the real monitor loop unchanged (the success path)
  • Checked for existing test coverage of these files (CLAUDE.md,
    SKILL.md, monitor-ci.sh) — none exists; they're agent-facing
    docs/scripts outside the BATS test suite's scope

CLAUDE.md and the /ci skill's own SKILL.md described a --commit SHA
flag for monitor-ci.sh, but the script only ever took positional args
([repos] [branch] [sha_pgxntool_test] [sha_pgxntool]) - that flag text
apparently crept in from ../ai/CLAUDE.md's general gh-CLI advice
(gh run list/gh pr checks do take --commit) getting conflated with this
script's own interface. An agent following the doc literally invoked
`monitor-ci.sh --commit SHA`, which silently misparsed into REPOS="--commit"
(falls through to the "both" default) with the SHA landing in BRANCH,
polling a nonexistent branch for ~35 minutes before timing out.

Also fixes SKILL.md's Usage line, which showed the wrong arg order/count
(<branch> <pgxntool-sha> <pgxntool-test-sha>, missing the leading
`repos` arg and with the two SHAs swapped relative to the script's real
sha_pgxntool_test/sha_pgxntool order).

Kept the positional interface rather than adding a --commit flag: "both"
mode (the default) needs two separate SHAs for two separate repos'
pushes, so a single --commit flag can't express the primary use case,
and the positional form is already load-bearing in the release skill.
Added a guard so a future --flag-style invocation fails fast with a
usage message instead of silently misparsing and hanging until timeout.
@coderabbitai

coderabbitai Bot commented Sep 8, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 05cd5f73-4952-4842-9f70-5af2472f5331

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant