feat(cli): commit Homebrew formula updates directly

[ChiragAgg5k]

What does this PR do?

Makes the CLI publish workflow commit Homebrew formula updates straight to the tap's default branch instead of opening a pull request.

Every release previously opened a PR against appwrite/homebrew-appwrite that then waited on a human, so brew install appwrite lagged behind npm and the GitHub release until someone merged it.

Changes

templates/cli/.github/workflows/publish.yml — "Open pull request on Homebrew tap" becomes "Commit Homebrew formula update": commit to the checked-out default branch and push. It rebases onto the remote first, since another release can land between checkout and push, where the old code force-pushed a per-release branch and that was harmless.

The early-exit when the formula is already current is preserved. Checksums still come from the local build, unchanged.

Why not an off-the-shelf action

Both mainstream options were checked and neither fits:

• mislav/bump-homebrew-formula-action updates version, url, sha256, tag, revision — a single url/sha256 pair. It does support direct commits (create-pullrequest: false), but it requires COMMITTER_TOKEN, a classic PAT with repo scope. That is broader and user-tied, a step back from the GitHub App this workflow already uses.
• dawidd6/action-homebrew-bump-formula wraps brew bump-formula-pr, taking tag/revision for a single source, and is pull-request shaped by design.

Both assume the common case: one source tarball, one checksum. This formula is a prebuilt multi-arch binary formula with four URLs across on_macos/on_linux × arm64/x64, each with its own sha256, and the URLs interpolate #{version} so they never literally change — only version and the four checksums do. Neither action can express that.

On losing the review step

Worth stating explicitly, since dropping the PR removes the only human look at those four checksums: the safety property does not come from the review, it comes from where the checksums are derived. They are hashed from the binaries this workflow just built, so the formula attests "this is the artifact we built." If anything differs from what ends up published, brew fails the checksum and refuses to install.

That also rules out an obvious-looking alternative: hashing the published assets instead. It sounds safer, but it makes the formula certify whatever is on the release, so a corrupted upload would get a checksum matching it and brew would install the corrupted binary silently. Hashing the build keeps the failure loud.

Permissions

This removes the last use of the bot token for pull requests. The app now needs only:

• Contents: read and write — clone, commit, push
• Metadata: read-only — mandatory for all apps

Pull requests: write can be dropped, so this is strictly less access than before.

Note the tap's main is currently unprotected, which is what makes a direct push work. If branch protection requiring a PR is ever enabled there, the push will fail in a way that looks like a permissions problem but is not — the app would need adding to the "allow specified actors to bypass required pull requests" list.

Test Plan

• ruby -ryaml parses the workflow; 21 steps load, ending in the new commit step.
• The modified run block passes bash -n.
• php example.php cli console regenerates cleanly; the generated .github/workflows/publish.yml is byte-identical to the template, confirming the copy scope passes it through unchanged.
• composer refactor:check — Rector clean.
• composer lint-twig — 44 errors with and without this change; all pre-existing, none in the touched file.
• No gh pr usage or bot-token GH_TOKEN remains in the Homebrew steps.

Related PRs and Issues

Follow-up to appwrite/sdk-for-cli#346. The 23.2.0 publish run failed at the Homebrew step because vars.APPWRITE_BOT_APP_ID and secrets.APPWRITE_BOT_PRIVATE_KEY are not set on sdk-for-cli, so the formula had to be bumped by hand in appwrite/homebrew-appwrite#32. That credential gap is separate from this change and still needs fixing, or this step will keep failing before it can commit anything.

Have you read the Contributing Guidelines on issues?

Yes.

[greptile-apps]

Greptile Summary

The workflow now publishes Homebrew formula updates directly to the tap.

• Replaces pull-request creation with a commit, rebase, and push to the checked-out default branch.
• Removes the GitHub CLI pull-request metadata and bot-token environment variables from the final step.

Confidence Score: 3/5

The PR is not yet safe to merge because concurrent releases can still make the later Homebrew formula update fail during rebase.

The workflow has no concurrency control and commits formula changes before rebasing, so two release runs that update the same version and checksum lines can conflict and leave the tap pinned to the earlier release.

Files Needing Attention: templates/cli/.github/workflows/publish.yml

Important Files Changed

Filename	Overview
templates/cli/.github/workflows/publish.yml	Replaces the Homebrew pull-request flow with a direct commit and push, but the previously reported concurrent-rebase failure remains.

_{Reviews (4): Last reviewed commit: "feat(cli): commit Homebrew formula updat..." | Re-trigger Greptile}