feat(release): authenticate release-please via GitHub App

[fiunchinho]

Summary

• Switch the release.yaml reusable workflow (release-please wrapper) from a long-lived PAT (TAYLORBOT_GITHUB_ACTION) to a short-lived GitHub App installation token minted by actions/create-github-app-token.
• Caller secrets are now RELEASE_PLEASE_CLIENT_ID and RELEASE_PLEASE_PRIVATE_KEY (org-level secrets, available to all repositories).

Why

• Downstream workflows run on release PRs. Commits/PRs created by a GitHub App token trigger other workflow runs, whereas the default GITHUB_TOKEN does not. This means CI runs on the release PR like any normal PR.
• No bot user seat. A GitHub App replaces the dependency on the taylorbot user account and its PAT lifecycle.
• Least privilege + short-lived tokens. App installation tokens expire after ~1 hour and are scoped to the App's declared permissions (contents: write, pull_requests: write).
• Better audit trail. Actions are attributed to the App rather than a human account.

Breaking change for callers

Repos that call this reusable workflow must update the secrets: they pass:

# Before
jobs:
  release:
    uses: giantswarm/github-workflows/.github/workflows/release.yaml@main
    secrets:
      TAYLORBOT_GITHUB_ACTION: ${{ secrets.TAYLORBOT_GITHUB_ACTION }}

# After (with org secrets accessible to all repos, `secrets: inherit` is enough)
jobs:
  release:
    uses: giantswarm/github-workflows/.github/workflows/release.yaml@main
    secrets: inherit

The new required secrets are RELEASE_PLEASE_CLIENT_ID and RELEASE_PLEASE_PRIVATE_KEY, both provisioned at the organization level with access to all repositories.

Notes on conventions

• Pinned actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0, matching the pin used by other workflows in this repo (fix-vulnerabilities.yaml, dispatch-update-chart-*.yaml).
• Uses the client-id: input parameter on create-github-app-token. GitHub now recommends client-id over the deprecated app-id input.
• The secret name is RELEASE_PLEASE_CLIENT_ID to match the value it actually holds (the App's Client ID, e.g. Iv23li...). This is more explicit than the HERALD_APP_ID/client-id: pairing used by fix-vulnerabilities.yaml and the dispatch workflows in this repo — we may want to align those in a follow-up, but they're left untouched here.

Test plan

• Pick a low-risk consumer repo and update its caller workflow to use secrets: inherit (or to pass the two new secrets explicitly). Push a conventional commit to main and confirm:
  • The release PR is opened by the GitHub App (commit author / PR author show the App, not taylorbot).
  • Other CI workflows in that repo run against the release PR (this is the key win vs. GITHUB_TOKEN).
  • On merging the release PR, the tag and GitHub Release are created as before.
• Audit other consumers of release.yaml and coordinate their migration.

[fhielpos]

Bear in mind that APP_ID and CLIENT_ID are not the same for this action. We had to update the secret for some other actions recently because of this.

[QuentinBisson]

Are you sure about the release please name for the app id and client id? Maybe autoapprove or smth else might fit better?

[fiunchinho]

Bear in mind that APP_ID and CLIENT_ID are not the same for this action. We had to update the secret for some other actions recently because of this.

Good catch! I just changed it to use only the APP_ID. PTAL.

Are you sure about the release please name for the app id and client id? Maybe autoapprove or smth else might fit better?

But we will use this same App for creating the release PRs, right?

[QuentinBisson]

@fiunchinho I think this is really good but we might be missing the auto-release flag that was reverted here 6aad5af?

[fiunchinho]

@fiunchinho I think this is really good but we might be missing the auto-release flag that was reverted here 6aad5af?

I'd say let's tackle the auto merge in a different PR