Revert CAT_TOOLS_GIT_REF override now that cat_tools 0.3.0 is on PGXN

[jnasbyupgrade]

Revert the CAT_TOOLS_GIT_REF override now that cat_tools 0.3.0 is on PGXN, and automate the check that a release must never be cut while it's set.

• ci.yml: workflow-level CAT_TOOLS_GIT_REF reverted to empty since a plain pgxn install now satisfies META.in.json's declared floor; left declared (not deleted) as a documented knob for if PGXN's cat_tools ever goes stale again.
• ci.yml: pg-tle-test gets its own job-scoped CAT_TOOLS_GIT_REF, empty by default and falling back to the stable tag, since it always clones cat_tools from source for pg_tle registration independent of the release-gated variable above.
• New bin/in_release plus a release-safety CI job hard-fail if a real version is ever set while CAT_TOOLS_GIT_REF/CAT_TOOLS_SKIP_INSTALL is non-empty, automating the "never release with the override set" check that used to be manual only.
• RELEASE.md states this explicitly for whoever runs the release process: the automated job is a backstop, not a substitute for checking by hand first.

bin/in_release's fail condition was checked by hand against all three states (stable+no-override, stable+override, real-version+override), since CI itself never legitimately exercises the failing case — that's exactly the state this guards against.

[coderabbitai]

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: Pro Plus

Run ID: 5329e307-8086-48a7-911b-cdbbafbc7e69

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[github-actions]

Claude finished @jnasbyupgrade's task in 1m 6s —— View job

---

Code Review

Tasks:

• Read trigger request and repo CLAUDE.md
• Review diff (.github/workflows/ci.yml, RELEASE.md removal)
• Check reasoning against ../ai/RELEASE.md guardrail
• Verify pg-tle-test job-level override is correctly scoped
• Post review feedback

Summary

This is exactly the release-blocking cleanup the PR description says it is, and the diff backs it up:

• META.in.json:82 declares "cat_tools": "0.3.0" as the floor, and Makefile:104 installs via pgxn install 'cat_tools>=0.2.1' --sudo — with 0.3.0 now on PGXN, that plain install satisfies the declared floor without the workflow-level override.
• Removing the top-level CAT_TOOLS_GIT_REF: 0.3.0 env (.github/workflows/ci.yml:17-26 in the old version) correctly un-blocks the release per the guardrail the (now-deleted) RELEASE.md described.
• The pg-tle-test job's new job-level CAT_TOOLS_GIT_REF: 0.3.0 (ci.yml:311) is correctly scoped — that job clones cat_tools from git directly for pg_tle registration (never through PGXN/filesystem install), so it never picked up the Makefile's pgxn install path and genuinely needs its own explicit ref. Decoupling it from the top-level override is the right call.
• The removed CAT_TOOLS_GIT_REF=$(make -s print-CAT_TOOLS_GIT_REF ...) shell dance is replaced with the value already being in the job's env — simpler and correct, since the job-level env: is visible to the run: step.
• Deleting RELEASE.md is reasonable: its only content was documenting this one override, which this PR resolves, and the generic guardrail already lives in the shared ../ai/RELEASE.md. Confirmed no other file in the repo links to the deleted RELEASE.md.
• CI on this PR is green (fresh-install matrix, pg_tle job, pg_upgrade job all passed), which is the load-bearing verification for a change like this.

No issues found. Nothing to flag, no suggested fixes.

[github-actions]

Claude finished @jnasbyupgrade's task in 2m 19s —— View job

---

Code Review

Tasks:

• Read trigger request and repo CLAUDE.md
• Review diff (.github/workflows/ci.yml, RELEASE.md, new bin/in_release)
• Check reasoning against ../ai/RELEASE.md guardrail
• Verify pg-tle-test job-level override is correctly scoped
• Review new bin/in_release script
• Post review feedback

Summary

This push (commit f96ae0e) builds on the earlier revert by automating the guardrail it previously relied on manual review for. The diff is clean and internally consistent:

• bin/in_release (ci.yml:55, new file) is a small, correct predicate: it greps default_version out of extension_drop.control and exits 0 only when it's a real version (mid-release) rather than the stable placeholder. set -euo pipefail plus the default arg (${1:-extension_drop.control}) resolve correctly against the repo root, which is where the new release-safety job invokes it from after checkout. Executable bit is set (mode 100755).
• release-safety job (ci.yml:44-57) correctly fails only when both conditions hold: bin/in_release is true (cutting a release) and CAT_TOOLS_GIT_REF/CAT_TOOLS_SKIP_INSTALL are non-empty. Since the workflow-level env: block was removed in the prior commit, those vars are unset in this job's environment (no set -u, so $CAT_TOOLS_GIT_REF$CAT_TOOLS_SKIP_INSTALL safely expands to "") — the check is a no-op today and only fires if someone re-adds the override at the workflow level in the future, which is exactly the scenario it's meant to catch.
• It's correctly wired into all-checks-passed's needs: list (ci.yml:427), so a future accidental override would actually block merge rather than just failing silently.
• pg-tle-test's CAT_TOOLS_GIT_REF: "" (ci.yml:326) is now empty-by-default with a fallback to the stable git tag (ci.yml:375: checkout "${CAT_TOOLS_GIT_REF:-stable}") rather than hardcoding 0.3.0 as the PR description originally proposed. This is a nice improvement over the original plan — it means this job won't need a manual bump the next time cat_tools cuts a release, and it stays decoupled from release-safety's workflow-level check (job-level env never leaks across jobs in Actions, so there's no interaction between the two).
• Confirmed no dangling references: the old make print-CAT_TOOLS_GIT_REF target and its call site are both gone (removed together, nothing orphaned).
• RELEASE.md now documents why a local copy exists again (the automated check itself, per the file's own reasoning about when a repo needs repo-specific content) — consistent with the file being deleted in the prior commit for the opposite reason.

No issues found. Nothing to flag, no suggested fixes.

[github-actions]

Claude finished @jnasbyupgrade's task in 1m 35s —— View job

---

Code Review

Tasks:

• Read trigger request and repo CLAUDE.md
• Review diff since last review (commit defceef, git diff origin/master...HEAD)
• Check reasoning against ../ai/RELEASE.md guardrail
• Verify bin/in_release and release-safety job logic still hold
• Post review feedback

Summary

This push (commit defceef) is a small, well-reasoned follow-up to the automation added in f96ae0e. It reintroduces CAT_TOOLS_GIT_REF as an explicit, empty top-level env: knob in .github/workflows/ci.yml:20-26, and restores an explicit "never release with this set" warning in RELEASE.md.

• No functional/behavioral change. Makefile:88 already does CAT_TOOLS_GIT_REF ?=, so an unset var and an explicitly-empty-string var behave identically for every [ -n "$CAT_TOOLS_GIT_REF" ] check in the Makefile (Makefile:97) and in release-safety (ci.yml:62). Declaring it explicitly is purely documentation/discoverability — the stated purpose in the commit message ("keep the framework for using it again") — and that's accurately reflected: no test or job behavior differs from the prior commit.
• release-safety (ci.yml:54-65) still functions correctly. It reads $CAT_TOOLS_GIT_REF$CAT_TOOLS_SKIP_INSTALL from the job's actual environment regardless of whether either is declared at the workflow level, so this change doesn't weaken or bypass that gate.
• pg-tle-test's job-level CAT_TOOLS_GIT_REF: "" (ci.yml:333) remains correctly decoupled from the new workflow-level one — job-level env shadows workflow-level env for that job only, consistent with the comment there.
• Minor inconsistency, not a bug: RELEASE.md:9-11 tells a human to check ci.yml's top-level env: for either CAT_TOOLS_GIT_REF or CAT_TOOLS_SKIP_INSTALL, but only CAT_TOOLS_GIT_REF is actually declared there (ci.yml:26) — CAT_TOOLS_SKIP_INSTALL has no top-level placeholder. Harmless today (nothing sets it, and release-safety checks the real env regardless of declaration), but if the intent is really "give both knobs the same explicit/discoverable treatment," CAT_TOOLS_SKIP_INSTALL: "" could be added alongside it for symmetry. Purely optional/cosmetic.
• CI on this commit (32418191976) is green.

No issues found that block merge. Nothing else to flag.