PR Approval Workflow Automation#

The asyncapi/generator repository enforces a maintainer-triage gate: every issue must carry an Approved Issue label before a contributor's PR can stay open. Three GitHub Actions workflows implement the gate end-to-end; a bot-author bypass and a downstream automerge workflow handle automation-generated PRs that fall outside the gate.

Label State Machine#

Issue opened
     │
     ▼
[Awaiting Approval] ◄─ applied to every new issue (color fbca04)
     │
     │ maintainer comments /approve
     ▼
[Approved Issue] ◄─ PR can now remain open (color 0e8a16)

PRs that reference an issue still tagged Awaiting Approval, or that have no issue reference at all, are automatically closed by the enforcement workflow 1.

Workflow 1 — issue-awaiting-approval.yml#

Trigger: issues.opened

Applies the Awaiting Approval label (hex fbca04) to every newly opened issue. If the label does not yet exist in the repository, it is created first using a 422-idempotent guard so that concurrent runs cannot fail. See .github/workflows/issue-awaiting-approval.yml.

Workflow 2 — issue-approve-command.yml#

Trigger: issue_comment.created where the body is exactly /approve or starts with /approve 2

The workflow is skipped for PR threads and closed issues 3.

Authorization is derived at runtime from CODEOWNERS. The workflow sparse-checks out only that file, finds the catch-all * line, extracts all @handles, and filters out any username containing "bot" 4. This keeps the authorized approver list in sync with CODEOWNERS without hard-coding usernames. Only the catch-all line is used — path-specific CODEOWNERS entries (e.g. packages/, *.md) do not grant /approve rights 5.

The current catch-all * line is:

* @derberg @magicmatatjahu @jonaslagoni @Adi-204 @asyncapi-bot-eve

After bot-filtering, the effective approvers are derberg, magicmatatjahu, jonaslagoni, and Adi-204.

On a valid /approve, the workflow 6:

1. Removes Awaiting Approval
2. Adds Approved Issue (creates the label if absent, 422-idempotent)
3. Posts a contributor instruction comment crediting the approver

Unauthorized attempts receive an error comment listing who can approve 7. Already-approved issues receive a short notice and no label changes 8.

Key gotcha: @Florence-Njeri (Docs Champion) is listed as a CODEOWNER for specific paths but cannot use /approve because the workflow only reads the catch-all line. To grant approval rights, add the username to the * catch-all line in CODEOWNERS, not a path-specific entry 4.

Workflow 3 — close-prs-for-unapproved-issues.yml#

Trigger: pull_request_target — opened, edited, reopened 9

pull_request_target (not pull_request) is used so that GH_TOKEN has write access to close fork-originated PRs and post comments 9.

Bot-author bypass: The workflow first checks the PR author against a hardcoded allowlist — asyncapi-bot, dependabot[bot], dependabot-preview[bot], github-actions[bot] — and returns early without enforcement if matched 10. This bypass was added specifically to prevent changeset release PRs and dependency-bump PRs from being auto-closed (see issue #2249).

Issue-link detection: The PR body is scanned with the regex /(close[sd]?|fix(?:e[sd])?|resolve[sd]?)\s#(\d+)/gi to extract linked issue numbers 11.

12

Bot PRs & Automerge#

Automated PRs bypassed by the enforcement workflow are handled downstream by .github/workflows/automerge.yml 13. That workflow auto-approves bot PRs using GH_TOKEN_BOT_EVE, applies autoapproved/autoupdate labels, and squash-merges them. It is centrally managed in asyncapi/.github and should not be edited in this repo.

Incident Reference: Bot PR Auto-Close (2026-09-17)#

Within hours of the gate being deployed via PR #2192, the changesets release PR #2248 was auto-closed 8 seconds after opening, blocking the 3.5.0 release pipeline. The original workflow had no bot-author bypass (issue #2249). The fix — the botAuthors allowlist check — was shipped in the updated workflow 10.

Quick Reference#