Use the shared automation GitHub App for the Homebrew tap bump, not a PAT

[MihaiBojin]

#29 adds a step that notifies releasetools/homebrew-tap when a release ships, gated on a HOMEBREW_TAP_TOKEN secret that does not exist yet. Rather than create a PAT, this should use the automation GitHub App that releasetools/terraform-github-app already provisions.

Why a token is needed at all

GITHUB_TOKEN is scoped to the repository running the workflow, so it cannot POST /repos/releasetools/homebrew-tap/dispatches. The repository_dispatch trigger works fine with GITHUB_TOKEN — that's an explicit exception in the docs — but the cross-repo authorization is the blocker, not the trigger.

The second reason, which matters more

The tap's bump workflow (releasetools/homebrew-tap#16) opens a PR. Per GitHub's docs:

When a pull request is created or updated by a workflow using GITHUB_TOKEN, pull_request events with the opened, synchronize, or reopened activity types create workflow runs that require approval.

So a bump PR opened with GITHUB_TOKEN sits with its CI gated pending approval — and that CI is brew test-bot --only-formulae, the only thing standing between a bad formula and users. An automated bump whose verification doesn't run unattended is most of the way back to the silent-no-op problem this whole thread has been about.

An App installation token is not subject to that restriction, so the bump PR gets tested immediately. It also removes the dependency on Settings → Actions → Allow GitHub Actions to create and approve pull requests being enabled on the tap.

Why not a PAT

• Tied to a person — it dies when they rotate it, lose access, or leave
• Long-lived by default; App installation tokens expire in an hour
• Audit trail reads as a human, not as automation
• Per-repo scoping is manual, whereas the App installation's repo access is already managed as code in terraform-github-app

What already exists

terraform-github-app creates the App from manifest.json, stores GH_APP_CLIENT_ID / GH_APP_ID as org variables and GH_APP_PRIVATE_KEY as an org secret, and pins installation access with Terraform. multirepo/.github/workflows/terraform.yml already consumes it:

- name: Generate a GitHub App token
  uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
  id: app-token
  with:
    client-id: ${{ vars.GH_APP_CLIENT_ID }}
    private-key: ${{ secrets.GH_APP_PRIVATE_KEY }}
    owner: ${{ github.repository_owner }}
    repositories: |
      ${{ github.event.repository.name }}

So this is wiring, not new infrastructure.

What's missing

manifest.json currently declares:

"default_permissions": {
  "administration": "write",
  "environments": "write",
  "issues": "write",
  "contents": "write",
  "metadata": "read",
  "secrets": "read",
  "organization_secrets": "read"
}

contents: write already covers both sending the dispatch and pushing the bump branch. pull_requests: write is absent and is required to open the bump PR.

Note that editing manifest.json only affects newly created Apps — an existing App's permissions have to be changed in its settings, and the installation must then approve the new permission.

Tasks

• Add "pull_requests": "write" to manifest.json in terraform-github-app
• Update the existing App's permissions to match, and approve the permission request on the installation
• Pin the installation's repository access to include releasetools/cli and releasetools/homebrew-tap
• In releasetools/cli release.yaml, mint an App token scoped to homebrew-tap and use it for the dispatch, replacing secrets.HOMEBREW_TAP_TOKEN
• In releasetools/homebrew-tap bump-formula.yml, mint an App token and use it for the branch push and gh pr create, replacing github.token
• Keep the no-token path a ::notice:: rather than a failure, so a release is never blocked by App misconfiguration
• Fix the terraform-github-app README, which describes Contents as read while the manifest says write

Acceptance criteria

• Tagging a release causes the tap to open a bump PR without human involvement
• That PR's brew test-bot runs immediately, with no approval step
• No PAT exists anywhere in the flow
• A release still succeeds if the App is unavailable, falling back to the tap's daily schedule

Refs

• Notify the Homebrew tap on release, and drop the retired macos-13 runner #29 — adds the notify step and the HOMEBREW_TAP_TOKEN placeholder
• Bump the formula from the upstream release, not Renovate homebrew-tap#16 — the bump workflow and bump-formula.sh