feat: add setup_script hook to prepare-release reusable workflow

[synchwire]

Summary

Adds an optional `setup_script` input to `prepare-release.yml` that runs as a bash step on the runner immediately after checkout and before any of the release tooling is installed. The script can install system tools, download toolchains, and write to `$GITHUB_ENV` to set environment variables that subsequent steps (including the `Prepare release` step) will see.

Why

The reusable workflow installs a fixed set of release tools and then invokes `holochain_release_util prepare`, which runs `cargo-semver-checks` against the workspace. Workspaces that contain crates with native build dependencies (an LLVM toolchain for `llvm-sys`, system libraries pulled in via bindgen, etc.) cannot use this workflow today: the prepare step fails before semver checks can run because the runner has no LLVM / no libfoo / no whatever installed, and there is no way to inject a setup step from the call site of a reusable workflow — GitHub Actions has no "steps before a reusable workflow" composition mechanism.

The motivating case is `holochain/holochain-wasmer`, whose host crate has a `wasmer-sys-llvm` cargo feature that pulls in `llvm-sys = "211"`. Today the only options for that repo are:

1. Fork the entire reusable workflow locally and add an LLVM install step, taking on permanent drift risk against this upstream every time it changes. Already considered and rejected.
2. Pass `--i-am-so-sorry-but-my-features-clash` via `extra_release_util_args`, which downgrades semver coverage from `--all-features` to `--default-features` for the whole workspace. Currently in flight at holochain/holochain-wasmer#185 as a tactical workaround.

Both are workarounds for a missing extension point in the reusable workflow itself. After this hook lands and a new release of `holochain/actions` is cut, holochain-wasmer can replace its `extra_release_util_args` workaround with:

```yaml
setup_script: |
LLVM_DIR=$PWD/.llvm
mkdir -p "$LLVM_DIR"
curl --proto '=https' --tlsv1.2 -sSf \
"https://github.com/wasmerio/llvm-custom-builds/releases/download/21.x/llvm-linux-amd64.tar.xz\" \
-L -o - | tar xJ -C "$LLVM_DIR"
echo "LLVM_SYS_211_PREFIX=$LLVM_DIR" >> "$GITHUB_ENV"
```

…and recover full `--all-features` semver coverage.

Design notes

• Placement: after checkout, before tool installs. This lets the script affect the environment that the cargo tool installs see (in case any of them ever start needing system deps too), and gives callers a clean repo state to work with. Failing fast in setup is also nicer than failing after we've spent a few minutes installing release tools.
• Gated on `inputs.setup_script != ''`. When the input is unset (the default), the workflow's behaviour is byte-identical to the previous version. Existing consumers cannot regress.
• Bash-only. The script runs under `shell: bash`, which is consistent with the `Prepare release` step. Anything richer (Python, Node, custom tooling) can still be invoked from inside the bash script. `$GITHUB_ENV` writes are the standard mechanism for handing environment state between steps in GitHub Actions.
• Scoped to `prepare-release.yml` only for this PR. `publish-release.yml` has the same shape and would benefit from the same hook (the publish step also invokes `cargo` against the workspace and could hit the same native-dep wall), but that's a separate change with its own review surface and no immediate consumer asking for it. Happy to follow up.

Test plan

• YAML syntax validates with `python3 -c 'import yaml; yaml.safe_load(...)'`
• No-input behaviour: the new step is gated on `inputs.setup_script != ''`, so existing callers (every repo currently using the workflow at `@v1.6.0`) continue to run with the exact same step list as before
• Once tagged in a new release, `holochain/holochain-wasmer` will switch #185 over to use the hook and confirm a real prepare run completes against its full `--all-features` matrix

[cocogitto-bot]

✔️ 99a0525 - Conventional commits check succeeded.

[coderabbitai]

Warning

Rate limit exceeded

@synchwire has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 16 minutes and 8 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 16 minutes and 8 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a9cbd5f5-9ff6-4245-b01d-e2aff30be493

📥 Commits

Reviewing files that changed from the base of the PR and between b5d892d and 99a0525.

📒 Files selected for processing (1)

• .github/workflows/prepare-release.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/setup-script-hook

---

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 and usage tips.}