Gate secret-bearing and PR-code-executing workflows behind a maintainer /approve-ci command

[Adi-204]

Motivation

Following #2184, looked at how much of our CI a pull request can reach before a maintainer has looked at it.

The gap

GitHub's built-in "require approval for fork pull requests" setting only applies to pull_request runs from forks. It does not cover pull_request_target, which runs in the base repository context with access to repository secrets — a trigger GitHub's own docs flag as a known risk area. For that class of workflow we currently have no native approval step available.

Proposal (v1)

A /approve-ci PR comment command:

• A maintainer comments /approve-ci; the command verifies them against a hardcoded maintainer allowlist and applies a ci-approved label
• A small set of workflows stays skipped until that label is present
• Approval is sticky for the PR's lifetime — once approved, later pushes run normally
• Bot-authored PRs (asyncapi-bot, dependabot) bypass the gate, reusing the bot-exclusion conditions these workflows already have

Deliberately minimal: easy to review, easy to revert, room to tighten later.

Candidate workflows

Of 31 workflows, 21 are centrally managed from asyncapi/.github, so this covers locally-owned ones only. Three candidates:

Workflow	Reason
manual-netlify-preview.yml	pull_request_target with access to repository secrets
pr-testing-with-test-project.yml	executes PR-authored code (npm ci, tests)
verify-docs-up-to-date.yml	executes PR-authored code (npm ci, docs build)

Explicitly not proposed: lint-pr-title, verify-ai-disclosure, pr-review-checklist, welcome-first-time-contrib, issues-prs-notifications, automerge*, notify-tsc-members-mention. None checks out PR code, and gating them would delay reviewer feedback or leave required checks pending.

[SushanthMusham]

Hi @Adi-204! I'd like to work on this issue.

I will implement the /approve-ci gatekeeper workflow and update the candidate workflows to check for the ci-approved label (with bot exclusions).

Could you please assign this to me? Also, could you share the list of maintainer handles that should be included in the initial allowlist?

[Adi-204]

Hey @SushanthMusham, currently this is under “Discussion/QA” on the board, so I think we should discuss it with the other maintainers first. We have most of our workflows maintained in the .github repo, so we should evaluate how much sense it makes to add this feature at this point.

Maybe you could also research in a bit more detail which workflows would actually need the /approve-ci guard, since we probably don’t need to guard all workflows.

[SushanthMusham]

hi @Adi-204 , I have look at the all the workflows , and this is what I found :

1. automerge.yml : uses GH_TOKEN_BOT_EVE, GH_TOKEN , they have write access
2. manual-netlify-preview.yml : uses NETLIFY_AUTH_TOKEN, NETLIFY_SITE_ID, GH_TOKEN , (this can run pr code with secrets so this must be an issue
3. pr-testing-with-test-project.yml : it does run the pr code(npm ci) ,but doesn't use any secrets
4. verify-docs-up-to-date.yml : runs pr code (npm ci) , but doesn't use any secret

so I think we can do for these